463569 - Behavior of "All Tabs" button needs a preference

Status: VERIFIED WONTFIX

(Firefox :: Tabbed Browser, enhancement)

Description

[Kevin J]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b2pre) Gecko/20081106 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b2pre) Gecko/20081106 Minefield/3.1b2pre

There should be a way of going back to the old behavior of the "all tabs" button where the list of tabs was displayed when clicked instead of the new thumbnails window.  Maybe look at the "browser.ctrlTab.previews" parameter since that controls whether to display the thumbnails for <ctrl>-<tab> switching or add a new preference in about:config to change this behavior.

Reproducible: Always

Comment 1

[Tyler Downer [He/Him]]

This makes some sense.
Not platform specific though.

Comment 2

[Dão Gottwald [:dao]]

I don't think we're going to maintain both the old and the new behavior.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

There are some more people complaining this new all tabs panel. Before we close this as WONTFIX we should ask some of the ui folks to get their opinion on that.

Comment 4

[Dão Gottwald [:dao]]

Bug 436304 removed something like 270 lines of code only from tabbrowser.xml. We're not going to add that back, plus the complexity of being able to toggle between two modes, just for a hidden pref. You can ask for a visible pref, or you can ask for a straight backout of bug 436304. In these cases, please adjust the summary or file new bugs, although I'm pretty sure they will be wontfixed as well -- if UX wouldn't have been convinced of the new behavior, we wouldn't have done it in the first place.

Comment 5

[Sylvain Pasche]

Having a preference to switch to the old behavior is the quick or dirty solution for the underlying "usability regressions" that some people have expressed.  For instance, in the thread http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/b50b402c8337c7

When opening lots of tabs from a few pages that you keep open on the left of the tab bar, it is now less easy to get back to those leftmost pages (Benjamin's feedback).

If you have lots of tabs open that are visually very similar (bugzilla pages), it is now more difficult to scan through them to get to a specific one (Bob's feedback).

Comment 6

[Kevin J]

After reading that thread, I fall into the same group as Benjamin.  I have a few tabs that I always keep open and the old behavior of this button was a way where I could quickly switch to those tabs.

I dont think that this new behavior is necessarily bad behavior and there are definitely some people who like it so I dont think bug 436304 should be completely backed out, but I am wondering why there is not a way to individually decide on which behavior to use when one behavior greatly decreases the usability of the browser for at least some people.  It does not really matter to me where that preference is, I just suggested that a simple way to do it that made sense to me was to use the "browser.ctrlTab.previews" option.

Comment 7

[Dão Gottwald [:dao]]

This is starting to get annoying. Decoupling from bug 436304, as I'm trying to use that dependency list for actual work.

Comment 8

[Tony Mechelynck [:tonymec]]

Note: The "Tabs Menu" extension https://addons.mozilla.org/en-US/firefox/addon/1242 adds a "Tabs" menu on the menubar, listing all tabs by favicons & titles without thumbnails. This might be a workaround for some of the usability problems mentioned in the comments above.

Comment 9

[Mike Connor [:mconnor]]

Maintaining multiple implementations is not going to happen.  The cost of maintaining multiple codepaths and multiple combinations of those codepaths is high, and the more variations we keep in the core, the harder it is to maintain the app and iterate on features.  Extensions are useful for exactly this reason.  I suspect the Tabs Menu extension could trivially replace the previews pane as well (just as the Ctrl+Tab extension trivially replaced the tabs menu).

What we do need to do, rather than "just add a pref for the old behaviour" is try to iterate the design towards solving more of the use cases people care about.  Please file bugs on individual use cases which are not well-supported in the current iteration.

(This bug has been WONTFIXed twice, and now I'm marking it a third time, as module owner.  I will be rather unhappy if someone reopens it again.)

Comment 10

[Sylvain Pasche]

I'd add that note that some of these use cases should be covered by bug 464045.

Comment 11

[Sam]

(In reply to comment #10)
> some of these use cases should be covered by bug 464045.

But then it'll break Ctrl+Tab's intention to simply cycle between few last visited tabs.

Core issue here is that Ctrl+Tab now has killed 'List All Tabs' widget/functionality, and bug https://bugzilla.mozilla.org/show_bug.cgi?id=464045 only trying to cover what was broken by new Ctrl+Tab.

Comment 12

[Sam]

(In reply to comment #9)
> Maintaining multiple implementations is not going to happen.  The cost of
> maintaining multiple codepaths and multiple combinations of those codepaths is
> high, and the more variations we keep in the core, the harder it is to maintain
> the app and iterate on features.  

I completely understand, but why implement new features in a way that breaks the old features?
Is it the only way?

> Extensions are useful for exactly this
> reason.  

Than why don't we keep Ctrl+Tab as an extension? something external, that not breaks something I(user) expect to work.
Progress is only good as long it's not involving (involuntary) sacrifices.

> I suspect the Tabs Menu extension could trivially replace the previews
> pane as well (just as the Ctrl+Tab extension trivially replaced the tabs menu).

That's OK, except it wasn't updated in a year.
So what you say loyal users like me should do?
Wait until somebody tries to fix new candy cool features?

I do fully understand that quite possibly I'm considered minority by UX, and not you nor Mozilla has any obligations to people like me.
But is it a fair practice to take away something that can be critical even for a few people? Even in the name of progress and/or pleasing more glitz-attracted demographic. 

> What we do need to do, rather than "just add a pref for the old behavior" is
> try to iterate the design towards solving more of the use cases people care
> about.  

Fully agree on that. But do we have to allow painful gaps until suitable iteration finally replaces something that was actually used & appreciated?

> (This bug has been WONTFIXed twice, and now I'm marking it a third time, as
> module owner.  I will be rather unhappy if someone reopens it again.)

Mike, this is not the best of idea of pleasure for me either.
I'm here only because of a great deal of PITA, 
And a hope that reasonable solutions can always be created, when openness and mindset of adding true value prevails.

Regards,
Sam.

Comment 13

[Jennifer Morrow [:Boriss] (UX)]

There is something to the argument that users are very used to tab order.  Dao is right, that this has largely been settled for this version of Ctrl+Tab, but the view here as been heard and not dismissed.  I suspect in the future there will be ways to configure Ctrl+Tab to change the order from MRU to tab order, but for now this has been tabled.

Comment 14

[Sam]

Ctrl+Tab is great - as long as you mess what you like with it - I'm not using it, nothing hangs on it for me - no problem then.

What I was saying is - leave alone "List All Tabs" widget.
Putting there Ctrl+Tab with - find 0,1% difference - is not really smart if you know what I mean, and you forgive me for having such a PAIN from it.

For some people (is it really only me? do I have to drop everything in my life, to dedicate it so that you all hear at last?) "List All Tabs" - is THE WAY to navigate wast amounts of tabs we have ... 

Even when you have: great, efficient, smart, & TUNABLE Ctrl+Tab (and when this when?), why you have to cut out people who used to the ways it works for them?
Why it should be - My Way of Highway? (it is when you have no choice ...)

Really hoping I'm not talking to robots already ...

Comment 15

[Fritz]

I couldn't agree more with you Sam.  When I need last ordered I do ctr+tab or I cna use the search box there.  List all tabs I went to when I wanted to find one of my 50 tabs and I (generally) knew what area of the list it would be in.  It is far simpler than guessing which of the 6 pages it will be on.  Ctrl+tab and list all tab now perform the same function and, oddly enough, for list all tabs, listing all tabs is not the function.

I hope that posting comments here is not a problem since this is now a bug _just_ for that since it has been verified won't fix.

Comment 16

[Tony Mechelynck [:tonymec]]

(In reply to comment #14)
> Ctrl+Tab is great - as long as you mess what you like with it - I'm not using
> it, nothing hangs on it for me - no problem then.
> 
> What I was saying is - leave alone "List All Tabs" widget.
> Putting there Ctrl+Tab with - find 0,1% difference - is not really smart if you
> know what I mean, and you forgive me for having such a PAIN from it.
> 
> For some people (is it really only me? do I have to drop everything in my life,
> to dedicate it so that you all hear at last?) "List All Tabs" - is THE WAY to
> navigate wast amounts of tabs we have ... 
> 
> Even when you have: great, efficient, smart, & TUNABLE Ctrl+Tab (and when this
> when?), why you have to cut out people who used to the ways it works for them?
> Why it should be - My Way of Highway? (it is when you have no choice ...)
> 
> Really hoping I'm not talking to robots already ...

Sounds like you're ready for the "Tabs Menu" extension, which adds a "Tabs" menu on the menubar, with one line per tab in tab order, displaying favicon & title, and bold for the current tab.

Works with Firefox and the SeaMonkey Browser. Not sure about Shredder.