Closed Bug 324227 Opened 19 years ago Closed 18 years ago

Implement old tab close button as a preffable option.

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 2 beta1

People

(Reporter: ria.klaassen, Assigned: mconnor)

References

Details

(Keywords: fixed1.8.1) 

Per Bug 308396 the tabbar close button has disappeared.
I always use it a lot to decrease the amount of tabs quickly so this is very uncomfortable for me. Now I need to make a lot of mousemoves to get rid of the last opened tabs.
Steps to reproduce:

Open your browser and open 2 or 3 tabs like you normally do. Then perform a Google search in a new tab. From that search, open 6 or 7 other tabs with search results.
Now you're ready with the search, delete all 7 search tabs in one gesture :)

I personally think this close button shouldn't return.
Would be weird having multiple close buttons for a tab.
It's very easy to close all other tabs but the current (using the tab context menu).
(In reply to comment #2)
> It's very easy to close all other tabs but the current (using the tab context
> menu).
>
All but the current 3 tabs? Show me the option! :) 


Here's the .css for people that don't need the close button:
http://www.mozilla.org/support/firefox/tips#app_tabclose
but I'm sure that "close button haters" are already using that .css so they won't even see it when it comes back.
OS: Windows XP → All
Hardware: PC → All
The old behaviour will be available as a pref.
Assignee: nobody → mconnor
Flags: blocking-firefox2+
Summary: [trunk] Tabbar close button gone → Implement old tab close button as a preffable option.
(In reply to comment #5)
> The old behaviour will be available as a pref.
>
Great! :) 


This sounds like bloat. -> extension.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
So chasing close buttons all over the tabbar to close many tabs in succession is desirable?

Comments 5/7 contradict each other, and both come from developers in only a matter of hours... What's up here?
Reopening.  The amount of code that this will require is not clear, nor is the absolute supremacy of closebuttons on tabs apparent.  Needs more evaluation.

As a note, once we have a working tab overflow solution, I intend to default to fixed width tabs, which restores a lot of the fixed-position benefit.  The final makeup for tabbed browsing in Firefox 2 is not set in stone.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Mike, either we take the close buttons, or we don't. It's not worth creating a hidden middle ground in code because some people disagree with the new behavior. Please read the comments on my blog about why creating this sort of codepath duality is a bad idea. It is easy enough to add this functionality from an extension, and that's where it belongs. 

I am marking this bug WONTFIX again.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WONTFIX
It's also not about the _amount_ of code this would add. Much of the feature bloat I commented on in my posting linked above is small in implementation size, but altogether it is significant. It's about a way of approaching problems. An idealogy of lean efficiency versus trying to please everybody with hidden backdoors. Firefox has never been about the latter. 
An extension developer wishing to build an alternate to this would have to do the following:

- create a stylesheet loaded by the browser that hides the close buttons on tabs
- insert a close button at the end of the tab strip using DOM apis that closes the selected tab. 

That's it!
I would like to vote in favor of adding this option.

Many people close tabs by middle-clicking them and in such case the close button is redundant, takes space, and forces to be more careful when switching tabs. As Mike Connor said the supremacy of the new solution isn't obvious enough and we may expect a fair number of people angry for being left without a choice or forced to use extensions.

I don't know about the code bloat but as for the UI bloat, the Tabs section still is by far the least populated.
Ben, I was under the impression that mconnor wanted a UI pref, not a hidden pref.
VERIFIED: module owner decision to WONTFIX.
Status: RESOLVED → VERIFIED
Flags: blocking-firefox2+
What would such a preference be called? That sort of thing smacks of old-world design methodology. I don't think that mass-close is as common a use case in the market at large as many people think. We are talking about enabling tabbed browsing single window mode by default for all users. Real users don't multitask much. There are other available solutions to people who use mass-close anyway, such as the key binding. 

User testing showed that the close button at the right of the tab strip was not a discoverable means of closing the tab bar. Close buttons were implemented to improve this discoverability. We will user test the newer tabbed changes and if the new state does not prove a liability based on a combination of user testing and testing on the trunk, while improving the general usability of tabbed browsing for more /real users/, we will take them at the expense of power user conveniences. 

Using the fact that there is room in a preferences panel for more options is not a good justification for adding them. 
Is this WONTFIX to make it a UI pref, or is this WONTFIX to make it an about:config pref?  I agree that there's no reason to make it a UI pref.

However, this seems like the kind of thing that's trivial to keep around as an about:config pref, and there is a pretty significant (IMO, anyway, as I do this often) use case for it.  C-w isn't a viable alternative due to various focus bugs that we still have, where various pages end up with focus stolen to some entry box or other widget, not to mention when the cursor ends up on top of a windowed plugin.  Closing multiple tabs may be a "power user" feature, but it's those power users who are and have been the early Firefox adopters -- why piss them off with something this trivial?

You can say "they can add userChrome hacks or extension hacks" to fix this, but it sounds like that's an even worse situation -- we're punting to extensions to bandaid holes in our UI, resulting in people who want to fix one or two of these "holes" needing to maintain a ton of extensions (or worse, userChrome).
The problem is that even among power users, mass-close does not represent _every_ close operation, and my argument is that the close buttons are more intuitively located for most situations.

Maybe what mass-closers really want is "close all tabs after X". That's an even more efficient option - I can think of several use cases, and it sounds about as effective as "Close all other tabs" if not more so for some situations and doesn't involve any pref-flipping. 
We could follow the trend set by Windows Explorer and have shift-close cause the tab _and all its children_ to be closed.

As to having UI because our other UI is buggy... that's a stupid reason, let's fix those bugs instead.
(In reply to comment #20)
> We could follow the trend set by Windows Explorer and have shift-close cause
> the tab _and all its children_ to be closed.

This is a little scary; we have no concept of a tab child, let's not start using that terminology.  "Close all tabs after this one" is not a bad idea; maybe in the tab context menu?  Though should it be "Close this tab and all tabs after it" or "Close all tabs after this one" (meaning the current tab stays?)

> As to having UI because our other UI is buggy... that's a stupid reason, let's
> fix those bugs instead.

Sure, I agree, although some of them can't be fixed (mouse over windowed plugin case).

Vlad - context menu yes. Maybe replace "All other tabs" unless someone feels strongly for that. A lot of those tab context menu options are a little kooky. Close tabs after might be best since close all tabs after including this one on the first tab closes the window. I think this is an interesting idea independently of where the close buttons are located since it addresses the mass-close problem more efficiently and elegantly than any other piece of UI yet discussed. 
I agree with vlad on hixie's comments. Hixie told me about this earlier and it sounds interesting initially but when you think about it you're right, it's scary because if you re-use a tab for another purpose it becomes fodder for "magical destruction" at a later point. (And it's not clear how to make it avoid its doom, in the "Close those to the right" case you can drag any tabs you want to save to the left). 

As a FYI, a small amount of ownership information _is_ carried around by tabs, it's used for the reselect-on-close behavior, very very cautiously. 
By "child tab" I just meant those tabs that used to be marked reselect-on-close. Visiting a new URI would reset that. Doesn't seem that controversial to me. I'd be more worried about the lack of discoverability.
The workaround I have at the moment is: all tabs the same size, then I put my mouse on the close button of the third tab and when I click repeatedly the tabs to the right will disappear.
This css however kills another function (doubleclick), but the workaround is not usable when the tabs have different sizes.
The TabMix Plus extension still has the tabbar close button functionality, but I never wanted such an invasive extension (however very clever that they could make it). 
If ctrl-w doesn't do what the tabbar close button does due to focus bugs, perhaps as part of this UI rework we need to fix those bugs as well.
So I guess the criteria for Firefox is now, "we'll break anything we want and make FF do all kinds of ridiculous stuff as long as it's possible to write an extension to return to sane behavior".

Thanks guys.
No, the criteria is "we'll do real usability studies and adapt the browser to make it more usable to the majority of users".
Ok. For a minute I thought Goggle had just done a study that was unpublished and only included new users. I'm glad that it was a published study and included veteran users as well as new users. I mean, it would be kind of silly to say it was a majority of users if the study didn't include a representative sample.
On second thought, it'd probably be a good idea to put a link to that study in this bug so that people who come wandering in here to complain can be directed to the incontrovertable evidence of the correctness of this bug's WONTFIX resolution. All the conspiracy theorists and paranoids will be claiming ridiculous stuff such as, "the sample wasn't random," or "sounds like someone's pet personal preference masquerading as the result of a well-executed study," etc. Now we can show them the proof and end the whining. That's why I like open source software: no secret decisions and hidden agendas ... it's all out in the open. I am anxious to read the study and have a link to use for rebuttal against the complainers.
Good lord, if you don't trust the product's module owner to make unbiased, professional usability studies, then get a life and go elsewhere. In the meantime, the mature amongst us will continue to try to make a good product.
How do I know if he's qualified in statistical analysis or not? Why one standard for code (open to the world for inspection) and another for studies (trust us, it's how we say it is)?
The study we did was actually biased towards more experienced users, I think. I don't think we intended it that way, those are just the volunteers you get when you conduct a study in the bay area. The results showed that even for people who use computers all day, who consider themselves "power users" there were issues. That makes me worried about _real_ novices.

I am going to try and get sanitized results made publicly available for this and future studies. Some details we will never be able to share for confidentiality reasons (on the part of the participants).

Anyway this is all off-topic to this bug. 
(In reply to comment #20)
> As to having UI because our other UI is buggy... that's a stupid reason, let's
> fix those bugs instead.

We may not be able to fix those bugs in a way that's safe for the Firefox 2 branch, though.

For my use, closing a bunch of tabs with one click isn't the issue. The issue is that I am charged with tracking the status of hundreds of pieces of legislation in California. The way I do that is to open each bill's status page in a separate tab and then start closing the tabs while watching the same point on the screen (the bill's status). I have my database window open on top so I can type the status of each bill into the database. Needless to say that I don't want to jump back and forth with keyboard focus, nor would it work for any bill where I have opened the bill's text (PDF) since plugins steal keyboard focus. Without having the tab close button in one position, I have manually locate the close button and click it for each tab (137 times -- this morning's count).

I have no problem with an about:config pref to change this back to the old behavior. It's dictating to me that I cannot have the behavior that I came to rely on and based my workflow around unless I expend the effort to undo what is in my usage a regression that seems so repugnant.

It is not the change itself that is upsetting, but that this and other bugs, keep reminding me that I cannot rely on features in Firefox because I might get the rug pulled out from under me so to speak. I'm not talking about being sad that I can't browse porn faster, but that this puts a kink in my actual work.

PS - I meant veteran users of Firefox, not computers in general.
I don't want to spam anymore in this bug but I would just like to point out that mass-closing won't be a problem once we make the tab width fixed (which I assume we will when the overflow is introduced). You just start with the first tab you want to close and the next ones appear right in the same place.

If the tab width is fixed, what happens when you run out of horizontal space for new tabs? I hope not a new row, and a scroll bar would be even worse. Making a lot of "hacky" changes like putting an arbitrary fixed size on tabs and figuring out what to do when there are more open tabs than there is screen seems like the wrong path to me.
We're already planning to have overflow and fixed tabs, given what we do know about tabbed browsing (relatively little, in an overall "how common is use case X?" fashion, but we're working on that)
Fixed tabs can't really help much. You can have less than about 200px for each tab or you'll never be able to read the title even with only two tabs open. That leaves about 5 tabs across on my screen. I cannot imagine having 30+ rows of tabs open when I do my work the way I have been doing it. What would mean I needed vertical scrollbars just to see all of the tabs. The only other alternative is a horizontal scrolling of tabs, but doesn't that kind of defeat the usefulness of tabs? I mean, aren't they meant to be easier to switch to than other windows? That would make it more difficult, not easier.
No one said multiple rows were the answer, there's another bug assigned to me where we're discussing the options.  130+ tabs is tough to handle no matter what, and the current solution certainly didn't handle that case any better than anything we might do.
I'm sorry. I searched for an *open* bug assigned to you with a discussion of the tabbed browsing UI, but I didn't see any. Can you supply the bug number? Thanks.
(In reply to comment #41)
> I'm sorry. I searched for an *open* bug assigned to you with a discussion of
> the tabbed browsing UI, but I didn't see any. Can you supply the bug number?
> Thanks.
> 


https://bugzilla.mozilla.org/show_bug.cgi?id=221684
I'm sorry, i don't see how an option to allow people to continue browsing the way they're used to can be considered bloat.  Lord knows there's less useful stuff in about:config. And then afterwards if it turns out Ben's right and people don't use it, it can then be declared bloat and turned into an extension.

Hixie - good products don't get made on blind faith.
The Close Button extension from
   https://addons.mozilla.org/firefox/1950/
can counter this unlucky decision at least partly (once one has edited its install.rdf for the new version number). It's just real annoying that every time I seriously want to test a Firefox build on OS/2 I need to install it into the fresh profile and drag the button to the toolbar...
*** Bug 341611 has been marked as a duplicate of this bug. ***
*** Bug 344182 has been marked as a duplicate of this bug. ***
Fixed by recent tabbrowser work
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Status: REOPENED → RESOLVED
Closed: 19 years ago → 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Target Milestone: --- → Firefox 2 beta1
what is the about:config option for this fix?
(In reply to comment #48)
> 
That is user_pref("browser.tabs.closeButtons", 3);



(In reply to comment #49)
> (In reply to comment #48)
> > 
> That is user_pref("browser.tabs.closeButtons", 3);
> 

Is that in the documentation anywhere? Thanks.
It was implemented in Bug 318168.
(In reply to comment #51)
> It was implemented in Bug 318168.
> 

I didn't see it. Thanks.
(In reply to comment #50)
> Is that in the documentation anywhere?

http://kb.mozillazine.org/Browser.tabs.closeButtons



*** Bug 344799 has been marked as a duplicate of this bug. ***
(In reply to comment #53)
> (In reply to comment #50)
> > Is that in the documentation anywhere?
> 
> http://kb.mozillazine.org/Browser.tabs.closeButtons
> 

I'm not seeing where to get the option to put the X at the end.

This works great on Firefox 2.0 nightly Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060817 BonEcho/2.0b1 ID:2006081703 and I no longer need the TabX extension, but the trouble is the tabs are hard to distinguish, so the other one at the end IN ADDITION would be nice for when closing a bunch of tabs quickly so you don't have to hunt around for the moving target of an X.
(In reply to comment #55)
> (In reply to comment #53)
> > (In reply to comment #50)
> > > Is that in the documentation anywhere?
> > 
> > http://kb.mozillazine.org/Browser.tabs.closeButtons
> > 
> 
> I'm not seeing where to get the option to put the X at the end.
> 
> This works great on Firefox 2.0 nightly Mozilla/5.0 (Windows; U; Windows NT
> 5.1; en-US; rv:1.8.1b1) Gecko/20060817 BonEcho/2.0b1 ID:2006081703 and I no
> longer need the TabX extension, but the trouble is the tabs are hard to
> distinguish, so the other one at the end IN ADDITION would be nice for when
> closing a bunch of tabs quickly so you don't have to hunt around for the moving
> target of an X.
> 

I totally agree with this : The up right corner is a "natural" place to look for to close a tab, and it allows to close several tabs without moving. But when you're on a tab, you didn't move since you opened it and you want to close it, you might be nearer of the tab's title.. So having both the active button on the right and the close-by-tab button could be just nice. Maybe option 4 for browser.tabs.closeButtons ?
I have no idea how it was implemented, so we may just cause the devs to cry by asking for this ;)

Thanks for your job by the way !
(In reply to comment #56)

I second that, having a close button on the active tab and another one on the right would be a great synthesis of 1.5 and 2.0 behaviour.
Reopen and block Bugzilla Bug 345741 Improve "All Tabs" menu active/visible tab feedback?
Perhaps this isn't the best place to comment on it, but I want to say thanks for adding browser.tabs.closeButtons (and browser.tabs.tabMinWidth) to about:config.  I and a few friends of mine prefer the old 1.x settings, so this is most welcome.
(In reply to comment #56)
> (In reply to comment #55)
> > (In reply to comment #53)
> > > (In reply to comment #50)
> > > > Is that in the documentation anywhere?
> > > 
> > > http://kb.mozillazine.org/Browser.tabs.closeButtons
> > > 
> > 
> > I'm not seeing where to get the option to put the X at the end.
> > 
> > This works great on Firefox 2.0 nightly Mozilla/5.0 (Windows; U; Windows NT
> > 5.1; en-US; rv:1.8.1b1) Gecko/20060817 BonEcho/2.0b1 ID:2006081703 and I no
> > longer need the TabX extension, but the trouble is the tabs are hard to
> > distinguish, so the other one at the end IN ADDITION would be nice for when
> > closing a bunch of tabs quickly so you don't have to hunt around for the moving
> > target of an X.
> > 
> 
> I totally agree with this : The up right corner is a "natural" place to look
> for to close a tab, and it allows to close several tabs without moving. But
> when you're on a tab, you didn't move since you opened it and you want to close
> it, you might be nearer of the tab's title.. So having both the active button
> on the right and the close-by-tab button could be just nice. Maybe option 4 for
> browser.tabs.closeButtons ?
> I have no idea how it was implemented, so we may just cause the devs to cry by
> asking for this ;)
> 
> Thanks for your job by the way !
> 


I opened Bug 366511 – Need to have a close tab "X" on both tabs and the far right to address this shortcoming.
You need to log in before you can comment on or make changes to this bug.