1285812 - Allow switching tabs by scrolling in the tab bar when it doesn't overflow

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P3)

Description

[jeremy9856]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623084759

Steps to reproduce:

Hello,

Firefox should allow switching tabs by scrolling with the mouse wheel in the tab bar. It's really convenient and, for what it worth, Google Chrome have the feature.

In the mean time this add-on work well but that should be an integrated feature.

https://addons.mozilla.org/en-US/firefox/addon/tab-wheel-scroll/

Thanks !

Comment 1

[Kanchan Kumari QA]

Enhancement/feature request

I see this feature of Chrome on Linux but not on Windows.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Firefox uses the mouse wheel in the tabbar to scroll the tabs when they are overflowing. We won't be able to change tabs as that would break our current workflow. Tabs in Google Chrome don't overflow, they just get smaller.

At this point, it would be functionality better left for an add-on, allowing users to opt-in to the changed behavior that they want.

Comment 3

[jeremy9856]

I don't see how always, and not only when they are overflowing, switching tabs by scrolling with the mouse wheel in the tab bar will break anything ? Can you explain please ?

We make this feature optional anyway.

Comment 4

[jeremy9856]

I meant "We can make this feature optional anyway"

Comment 5

[:Gijs (he/him)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #2)
> Firefox uses the mouse wheel in the tabbar to scroll the tabs when they are
> overflowing. We won't be able to change tabs as that would break our current
> workflow. Tabs in Google Chrome don't overflow, they just get smaller.
> 
> At this point, it would be functionality better left for an add-on, allowing
> users to opt-in to the changed behavior that they want.

FWIW, we implemented this for tabboxes in general in bug 281192, but explicitly did not implement for the tabbrowser. I don't actually know why. Maybe Dão can enlighten us? One of the ideas was to only do this if the tabbar is *not* overflowing. I'm not against wontfix, but I would appreciate some more context. :-)

(In reply to jeremy9856 from comment #3)
> I don't see how always, and not only when they are overflowing, switching
> tabs by scrolling with the mouse wheel in the tab bar will break anything ?

Because if you can't see what you're switching to then being able to switch is pretty much useless. We could make the current tab be always in the middle of the overflowing tabbox (if it's not at the end), but that has other downsides, such as always moving the tabbar whenever you switch tabs.

It also makes it much harder to quickly find a tab you're looking for in a tab bar - you'd have to repeatedly click (or click-hold) the scroll buttons, which is annoying if you have a mouse wheel / scrolling touchpad that could do the job just as well.

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

I lack the context as to the decision in bug 281192, but having a UI widget that changes behavior based on if the content is longer is ripe for unexpected outcomes.

Imagine a text box that when not overflowing, scrolling moves the cursor through the text while when the text is overflowing it will scroll the text. Somewhat similar behavior, but different enough through the two states to cause confusion.

Comment 7

[Dão Gottwald [:dao]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6)
> I lack the context as to the decision in bug 281192, but having a UI widget
> that changes behavior based on if the content is longer is ripe for
> unexpected outcomes.

There's no other context, the concern was exactly the one you're voicing. Most users don't ever get enough tabs to overflow, though, so I'm not sure if that concern is severe enough.

Comment 8

[jeremy9856]

I really think that should be implemented. For me there is no valid reason to not implement it.
Try the add-on to test the feature. It's really useful.

https://addons.mozilla.org/en-US/firefox/addon/tab-wheel-scroll/

Comment 9

[jeremy9856]

Hello,

Is it possible to make it happen please ?

Comment 10

[jeremy9856]

It's really useful and it's a fairly simple thing to add and I hope it will be implemented :)

Comment 11

[jeremy9856]

Hello,

It's a fairly simple thing to add and I really don't understand why it's still not possible.
Can you add this to Firefox please ?

Thanks !

Comment 12

[Andre Klapper]

@jeremy9856: If you want some feature / bug fixed, either provide a patch, or (if you cannot) consider paying someone to write that patch for you, but please stop spamming bug reports with comments which add no useful information whatsoever and could be seen as just whining. Thanks.

Comment 13

[Dmitry Gutov]

(In reply to Andre Klapper from comment #12)
> @jeremy9856: If you want some feature / bug fixed, either provide a patch,
> or (if you cannot) consider paying someone to write that patch for you

Would a patch adding this behavior as an option be accepted, though?

Comment 14

[Alice0775 White]

When switching tabs with the mouse wheel, I think that you need considerably CPU power. Especially unloading tabs after session restore. 
Because, rendering occurs every time unloaded tab is selected by turning the mouse wheel.  If the desired tab is far away from the current tab, that problem will occur for all tabs in between them. It is no good idea.

Comment 15

[jeremy9856]

Nothing more than pressing Ctrl + Tab...

Comment 16

[Timvde]

For what it's worth: Tab Mix Plus currently provides shift+scroll to change tabs. I think this would be an acceptable compromise, not breaking the current workflow.

jaws stated in comment 2 that this is add-on functionality, but with 1246706 being WONTFIXed, I think this is not possible in a WebExtension world.

Comment 17

[DB]

Is this the proper channel to request this feature be enabled for the future WebExtension version of FF?  I've contacted plugin developers, but they all report that this feature won't be possible.

Comment 18

[Marco T]

I would also like this feature. The experience without it is just not the same.

I understand that part of the optimizations in Firefox Quantum come from prioritizing the current tab and quickly passing through tabs would disrupt that.

Maybe 1) the tab could actually become "current" only after the mouse pointer leaves the tabs area and 2) the feature could be optional. I am just desperate to find an equally convenient way to switch tabs.

Comment 19

[Stephanie Hobbs]

As someone else noted in bug 1246706, scrolling on the tab bar to change tabs is a feature of:

* anything using GTK+'s GtkNotebook
* anything using Qt's QTabWidget (which should include Opera, as I remember)
* anything using wxWidgets' wxNotebook (because it wraps GTK+ on Linux)
* Chrome/Chromium

It's so ubiquitous that I've come to rely on it, and Firefox not having it simply means it absolutely doesn't feel native to linux. Every single other native application I've used on linux has this feature and it's truly essential to me. I will not be able to upgrade past Firefox 56 without this feature. Note that Chromium doesn't implement this tab bar scroll on Windows, as it's non-native behaviour, and I think that's a fine decision. But please, make an effort to fit in, to be a good UX citizen on linux, and add this feature. Especially as you can no-longer "fix" it with addons.

Comment 21

[Dão Gottwald [:dao]]

Attachment: Bug 1285812 - Allow switching tabs by scrolling in the tab bar when it doesn't overflow. (Linux only)

Review commit: https://reviewboard.mozilla.org/r/199738/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/199738/

Comment 22

[Mathias Panzenböck]

> At this point, it would be functionality better left for an add-on, allowing users to opt-in to the changed behavior that they want.

This does not apply anymore since you removed the appropriate add-on APIs, letting us Linux user stranded.

Comment 23

[Maxime Corteel]

(In reply to Andre Klapper from comment #12)
> @jeremy9856: If you want some feature / bug fixed, either provide a patch,
> or (if you cannot) consider paying someone to write that patch for you, but
> please stop spamming bug reports with comments which add no useful
> information whatsoever and could be seen as just whining. Thanks.

Less people would whine if voting was enabled on Firefox issues. I'm not usually one to whine, but I don't see how users can influence the development of Firefox if they can't weigh in.

Comment 24

[:Gijs (he/him)]

(In reply to Maxime Corteel from comment #23)
> (In reply to Andre Klapper from comment #12)
> > @jeremy9856: If you want some feature / bug fixed, either provide a patch,
> > or (if you cannot) consider paying someone to write that patch for you, but
> > please stop spamming bug reports with comments which add no useful
> > information whatsoever and could be seen as just whining. Thanks.
> 
> Less people would whine if voting was enabled on Firefox issues.

Voting is enabled on bugzilla, also for Firefox issues. This bug, for instance, has 9 votes at time of writing. Obviously, votes aren't some kind of guarantee people will work on the bug - bug 25537 has 32 votes and a gazillion dupes filed, and we quite intentionally never fixed it (and, IMO, it was good for the web that we didn't). In any case, if you're concerned about user participation in bugzilla in general, this specific bug is not a good place to raise that. Instead, consider the firefox-dev mailing list ( https://wiki.mozilla.org/Firefox/firefox-dev ).

Fortunately for this bug, it's already assigned to someone and there's a patch up, so commenting/voting doesn't do anything. Let's just let Dão and Stephen get on with reviewing/improving/landing the patch.

Comment 25

[Adrian]

Regarding the patch, does this really disable scrolling as soon as there are too many tabs to fit in one line? Or does the main tab bar never overflow since tabs are made smaller and smaller?

Also, will this land for Windows too (since this bug has OS set to Linux now)?

Comment 26

[Mathias Panzenböck]

Just in case anyone wonders how scrolling on tabs looks like under e.g. KDE I made a quick video:
https://www.youtube.com/watch?v=Etc16CcYBUw

Tabs don't infinitely shrink under KDE either. Still, they have the scroll on tabs behavior that I am used to under Linux. :)

Comment 27

[brcha]

Shrinking tabs are a strange and wrong idea. As soon as they start shrinking, the usability starts shrinking as well. As a matter of fact, shrinking tabs is one of the reasons why I don't use Chrome or similar browsers.

I would prefer it if I were able to scroll the tabs like in pre-57 versions of Firefox, and just like in @panzi's video. And I'm pretty sure the author of Tab-Wheel-Scroll extension would be happy to port it to webextensions as soon as the functionality was added (or, someone else would port it). Just being able to scroll tabs before they overflow is a good thing, but I seriously doubt it would be overly complicated to enable catching mouse wheel events over tabs and enable some tabs.next()/.previous() methods in webextensions.

Comment 28

[DB]

I've found a solution that works for me, using a tool called AutoIt and this script by Github user Nurupo: https://github.com/nurupo/chrome-mouse-wheel-tab-scroller 
I've switched to Chrome now, to replace add-ons that were broken in Firefox 57, but I needed a replacement for scrolling tabs, and this tool fits the bill.  It supposedly works for Firefox, as well, so you might check it out.  Note that Windows 10 wouldn't let me install the pre-packaged executable.  I had to install AutoIt and then set up the script manually.  The source code is available and clean. 
I'm still hoping that this functionality returns to Firefox.  I held w/ Firefox for years, but with version 57 I no longer see anything unique about it vs. Chrome, aside from a less developed addon repository.  :(

Comment 29

[alain]

This code in Browser Console do the job on all platforms => https://gist.github.com/benoitryder/db1ed51ca0213b882806fad1f4540796

If Firefox can execute a Javascript code at startup, it will be great!

Comment 30

[Adrian]

BTW, chrome does not support this without outside hacks (autoit, autohotkey, etc), so having native support for it in Firefox would be a big plus :)

Comment 31

[Stephanie Hobbs]

Chrome does support this, but only on Linux. On windows the feature is disabled with no way to turn it on.

Comment 32

[Adrian]

Ah, good to know. So if this gets into FF on all OS it'll still be a plus ;)

Comment 33

[Gustav]

Is my bug ( https://bugzilla.mozilla.org/show_bug.cgi?id=1418003 ) a duplicate of this one?

From what I can tell the only differences is that this bug will only scroll-select when not overflowing and only on Linux, while mine is a option(disabled by default) to always do scroll-select regardless of OS.

Comment 34

[Adrian]

Since there is still "linux only" in the title, can you please confirm that it will be (at least) possible to enable it with an about:config switch on Windows as well once it ends up in a release?

I really don't want to switch to Linux or start using awful hacks like Autohotkey to get this functionality. The current patch doesn't seem to contain any OS-specific logic, but the "linux only" in the title worries me.

Comment 35

[Dão Gottwald [:dao]]

(In reply to Adrian from comment #34)
> Since there is still "linux only" in the title, can you please confirm that
> it will be (at least) possible to enable it with an about:config switch on
> Windows as well once it ends up in a release?

No, that's not part of this patch. Bug 1418003 would be about that.

Comment 36

[Frederick Zhang]

(In reply to panzi from comment #26)
> Just in case anyone wonders how scrolling on tabs looks like under e.g. KDE
> I made a quick video:
> https://www.youtube.com/watch?v=Etc16CcYBUw
> 
> Tabs don't infinitely shrink under KDE either. Still, they have the scroll
> on tabs behavior that I am used to under Linux. :)

I think this is the most intuitive design to handle it. Supporting scrolling by mouse wheel doesn't necessarily break the current workflow even if the tabbar overflows. It would consume a bit more resources and slow down the scrolling a little if you really have a bunch of tabs (say, ~50 tabs), but that's kind of a fringe case...

Or, if the team still doesn't want to compromise on this point, at least an API should be provided to allow developers to override the default behaviour. There has been some attempts/requests for this, e.g. https://github.com/Robbendebiene/Gesturefy/issues/40.

Comment 37

[Jan Brothánek]

(In reply to alain from comment #29)
> This code in Browser Console do the job on all platforms =>
> https://gist.github.com/benoitryder/db1ed51ca0213b882806fad1f4540796
> 
> If Firefox can execute a Javascript code at startup, it will be great!

The way to run javascript on startup to enable the whole thing is this: https://forum.manjaro.org/t/howto-enable-tab-switching-in-firefox-using-mouse-wheel/39954

Not sure if it works on other platforms than Linux though.

Comment 38

[JuanNM]

(In reply to Jan Brothánek from comment #37)
> The way to run javascript on startup to enable the whole thing is this:
> https://forum.manjaro.org/t/howto-enable-tab-switching-in-firefox-using-
> mouse-wheel/39954
> 
> Not sure if it works on other platforms than Linux though.

I can confirm the solution given in that article is working fine. My system info:

$ lsb_release --all
> No LSB modules are available.
> Distributor ID:	LinuxMint
> Description:	Linux Mint 18.3 Sylvia
> Release:	18.3
> Codename:	sylvia

$ firefox -version
> Mozilla Firefox 59.0.2

Such a simple and easy to add solution! Thanks for the link.

Comment 39

[JuanNM]

Can also confirm that the solution given in the Manjaro forum as pointed out in comment #37 also works on Windows 7.

Version info:

> systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
> OS Name:                   Microsoft Windows 7 Professional
> OS Version:                6.1.7601 Service Pack 1 Build 7601

> "C:\Program Files\Mozilla Firefox\firefox.exe" -version | more
> Mozilla Firefox 59.0.2

Comment 40

[JuanNM]

Lastly, I just finished testing that the same solution works too on Mac OS, with the same Firefox version:

> $ sw_vers
> ProductName:  Mac OS X
> ProductVersion: 10.13.4
> BuildVersion: 17E199

> $ /Applications/Firefox.app/Contents/MacOS/firefox -version
> Mozilla Firefox 59.0.2

Comment 41

[Jan Brothánek]

Thanks for testing the platforms! Just a comment the code from Manjaro forum - I liked the original Tab Wheel Scroll's setting for disabling wrapping tabs around - not to jump from the last to the first (and vice versa). You can achieve the same with overwriting 'true' to 'false' in 'gBrowser.tabContainer.advanceSelectedTab(..., true);' - line #11 and #14 in the 'bindings.xml'.

Comment 42

[Frederick Zhang]

I applied the solution above in Firefox Dev Edition in Linux and it works but not perfect like the old Tab Wheel Scroll plugin. No idea whether this function has landed in stable yet but in Dev you can hide the title bar in Customise. And with the title bar being hidden, if you move the cursor to the very upper border of your screen, it actually does not work (I guess it's due to the margin above the tabs). Perhaps I'm asking too much though...

Comment 43

[Dmitry Gutov]

This solution work perfectly for me, but I wonder if it's going to stop working in some not-to-distant new version of the browser. After all, it uses XBL, which is related to XUL, a technology that's going away.

Comment 44

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 46

[Dão Gottwald [:dao]]

Attachment: Bug 1285812 - Allow switching tabs by scrolling in the tab bar when it doesn't overflow. (Linux only)

Comment 47

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ffa678d05ff5
Allow switching tabs by scrolling in the tab bar when it doesn't overflow. (Linux only) r=stransky

Comment 48

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/ffa678d05ff5

Comment 49

[Pascal Chevrel:pascalc]

This should probably be added to release notes, Dao could you request an addition to relnotes? Thanks

Comment 50

[Mathias Panzenböck]

I want to thank everyone who worked on this! Thank you! :)

Comment 51

[Dão Gottwald [:dao]]

Release Note Request (optional, but appreciated)
[Why is this notable]: long-standing Linux integration request
[Affects Firefox for Android]: no
[Suggested wording]: On Linux, tabs can be switched by scrolling in the tab bar (*)
[Links (documentation, blog post, etc)]: /

*: as long as it doesn't overflow. Not sure if this should be part of the note...

Comment 52

[Pascal Chevrel:pascalc]

Thanks Dao, just added to nightly notes.

Ryan, this is something you'll want in beta notes next week.

Comment 53

[Sayed [:LiquidO2]]

I can verify that this feature is implemented in latest Nightly 65 on Arch Linux (x86_64)

Build ID 	20181205213623
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Comment 54

[Asif Youssuff]

Love to see attention given to minor quality of life requests from users (especially those that are for platform convention consistency), but this feels like a mistake. 

I realize that it would have likely been a far greater undertaking to make this modifiable via a WebExtension, but that strikes me as the right way to do this, for a couple of reasons:

* Some Windows users want this - this doesn't help them
* this behavior is no longer part of GTK3, so it isn't consistent with GTK apps anymore

This may continue to be relevant for consistency with QT based apps, but we aren't detecting a user's desktop environment to capture the platform convention before enabling this behavior.

The last point is simply that the same scroll wheel action in the same place does different things depending on the contents of the tab bar. This doesn't feel like great UX, so I don't think it belongs in the default browser (unless of course, platform convention dictates it). 

Aside: I wonder if there is a way to use this as an example blog post/documentation entry of a WebExtensions experiment (to enable this as a preference) given the small patch size here. Just a thought.

Comment 55

[Adrian]

For other windows users who are missing this feature, there is a very easy workaround to do this without having to install legacy extensions or add hacks like "userChrome.js": https://forum.manjaro.org/t/howto-enable-tab-switching-in-firefox-using-mouse-wheel/39954

However, I still hope for this to be added properly to Firefox on Windows, possibly behind an about:config flag if there are any cases where the behavior may be problematic.

Webextension support to handle mouse wheel events on the tab bar would be ideal, but I think this particular feature would also be a good candidate to be in Firefox itself... Is there *any* reason why someone would not want this? Scrolling on the tab currently simply doesn't do anything...

Comment 56

[Mathias Panzenböck]

> this behavior is no longer part of GTK3

Indeed. But certain gtk applications now implement it manually, because it just is a nice behavior (IMO).

> The last point is simply that the same scroll wheel action in the same place does different things depending on the contents of the tab bar.

Yes, personally I'd like it to always switch tabs, but since having so many tabs that you have to scroll is not a good way to work anyway I'm totally fine with it.

> we aren't detecting a user's desktop environment

That's another thing I'd like to have: KDE file dialogs (like Chrome does it). But this is the wrong bug for that.

Comment 57

[Alice0775 White]

If there are unloaded tabs (particularly, after Restore Previous Session),
All unloaded tabs located between the target tab from the current tab will trigger loading its content due to switching them.  It will be very high CPU/Memory usage and it is undesirable behavior.

Comment 58

[Asif Youssuff]

> Is there *any* reason why someone would not want this? Scrolling on the tab currently simply doesn't do anything...

Same reasons I provided above; platform consistency and internal consistency (of doing the same thing when a tab bar is overflowing vs. not). It's not a huge deal but feels a bit like a papercut to me.

Besides which, I don't actually like this behavior - even when it used to be present in other apps - when GNOME Web had it, it was annoying to me partially because it differed from Firefox, but beyond that because it just felt weird, especially on touchpads. 

See https://bugzilla.gnome.org/show_bug.cgi?id=630226 where it was removed from GTK. 

Opened Bug 1512493, which I fully expect will be very low priority, but figured I'd log it in the interest of quality.

> If there are unloaded tabs (particularly, after Restore Previous Session),
> All unloaded tabs located between the target tab from the current tab will trigger loading its content due to switching them.  > It will be very high CPU/Memory usage and it is undesirable behavior.

This feels expected to me if this bug is the desired behavior based on platform convention. Unfortunately, this is not expected in my current platform, but c'est la vie.

Comment 59

[Mathias Panzenböck]

Yes, that's for what I used scrolling on tabs under Chrome sometimes: trigger them to load. Otherwise I scroll on tabs to go through them one by one, viewing several things I previously opened in tabs. Or maybe rapidly changing back and forth between two tabs to compare something without having to avert my gaze from the point in question on the page.

Comment 60

[Asif Youssuff]

>Just in case anyone wonders how scrolling on tabs looks like under e.g. KDE I made a quick video: https://www.youtube.com/watch?v=Etc16CcYBUw

Just watched the video; I think it actually makes sense to follow the same behavior to reduce the weird inconsistency today where scrolling with an overflowed vs. not tab bar does different things - but only when the platform dictates it. Maybe that is the real fix for Bug 1511613 (on KDE) - "unpredictable" sums up the problem here pretty well. 

Note: I realize that GTK also doesn't have a concept of scrolling through the tab bar in the same way Firefox does it, but it makes more sense to me to have GTK implement Firefox's behavior here -- it is a real nicety, imo.

Comment 61

[Adrian]

> If there are unloaded tabs (particularly, after Restore Previous Session),
> All unloaded tabs located between the target tab from the current tab will trigger loading its content due to switching them. It will be very high CPU/Memory usage and it is undesirable behavior.

How is this a problem? If I restart my browser chances are good I want to load most tabs I had open. Also, I can always click a specific tab to activate it!

Besides that, keep in mind that many people have pretty powerful computers with more than enough memory and cpu power, so the memory usage of a bunch of tabs opening isn't really an issue for them.

Comment 62

[JuanNM]

(In reply to Alice0775 White from comment #57)
> If there are unloaded tabs (particularly, after Restore Previous Session),
> All unloaded tabs located between the target tab from the current tab will
> trigger loading its content due to switching them.  It will be very high
> CPU/Memory usage and it is undesirable behavior.

That's exactly expected and implied in this feature proposal, and still orders of magnitude better than Chrome's default of reloading ALL tabs on startup; _that_ is the actual CPU hog and undesirable behavior, if you ask me. And I'm someone with a mid- to low-end computer, for what is worth. I guess this is a case of https://xkcd.com/1172/

(In reply to Asif Youssuff from comment #58)
> > Is there *any* reason why someone would not want this? Scrolling on the tab currently simply doesn't do anything...
> 
> Same reasons I provided above; platform consistency and internal consistency
> (of doing the same thing when a tab bar is overflowing vs. not). It's not a
> huge deal but feels a bit like a papercut to me.

What is inconsistent is having this behavior in Chromium and in Chrome, but not in Firefox (yes, for different reasons I use all three of these at the same time). Then needing to remember which browser is currently active - or constantly having to realize it from the fact that scrolling tabs doesn't work. Chrome devs found out that it can be an useful feature, IMO it really is, and it's a good thing that now Firefox will follow that tiny design decision bringing more consistent behavior across the table between browsers (although I'd be fine having an extension that added this behavior). That GTK design decisions are the best overall, that's more debatable... but off topic. What is relevant is that browsers are now everyday tools for most of all, and when some behaviors become popular, they are expected, and it's good that they are there. Like how any file browser uses the same keyboard shortcut for copying and pasting stuff.

Specifically this feature makes even more sense in Firefox than in Chrome: FF does not load all tabs upon startup, which is a good thing especially if you keep tens of them open (e.g. with the state of some research you've been doing in the last days). When opening the browser, it is REALLY useful being able to make the browser load a specific set of those tabs, by opening the first one and quickly scroll through until the last one you want opened.

Of course, like most of these controversial changes, it probably could go into an "advanced settings" menu as to not alienate users.

Comment 63

[Asif Youssuff]

> That GTK design decisions are the best overall, that's more debatable... but off topic. 

Not what I am saying - I am simply saying that this is the platform convention, and that is what platform consistency *means*. 

> Like how any file browser uses the same keyboard shortcut for copying and pasting stuff.

Yes, those too are platform conventions - see https://support.microsoft.com/en-us/help/12445/windows-keyboard-shortcuts for an example. 

> What is relevant is that browsers are now everyday tools for most of all, and when some behaviors become popular, they are expected, and it's good that they are there.

Maybe, but this is not present cross-platform, only on Linux, even in Chrome, and my guess is that Google's intent was to follow platform convention -- not a decision to override platform convention for some more "popular" behavior that has become "expected". This is no longer a platform convention in GTK3, though, so that argument goes out the window!

Either way, we are beating a dead horse here, you have the feature, and indeed, I think it ought to be "improved" in the KDE case by default along with a configuration switch that allows always-on switching (never scrolling) - so I don't disagree with the feature at all, I just think that the configuration should be per platform convention, with a user override. 

Going to stop posting because I don't want to continue spamming this bug.

Comment 64

[Kestrel]

This exact behavior was previously proposed and rejected 9 years ago for the same reason as Bug 1511613 and the situation has remained unchanged since then other than tab switching being removed from GtkNotebook in GTK3 due to issues with modern wheels and touchpads (Bug 1512863).

(Mike Connor [:mconnor] from Bug 281192 comment #41)
> That seems strange to me... it definitely seems like inconsistent UI to me,
> since as soon as I go to overflow, my interaction model breaks...
> 
> review?([e-mail]) → review-

Comment 65

[jmkrnet]

First I would like to thank Dao and others who helped to implement the tab switching via scrolling (aka the feature).



The following is my reply to the comments 54, 58, 63 and 64 of Asif Youssuff and Kestrel especially with regards to their bugs 1512863 and 1512493:

I have just read the comments in relevant GNOME bugs https://gitlab.gnome.org/GNOME/gtk/issues/234 and https://bugzilla.gnome.org/show_bug.cgi?id=630226 - my impression could be summarized by the following:

1) A useful feature was removed because some GNOME UI experts found "it could be confusing to a new user" (what a universally applicable reason that is also empty and tells nothing to anybody who reads it:).

2) The further reasoning explains that a user is confused because of having a mouse that scrolls too smoothly. Maybe now this confused new user could use a touchpad or touch screen or what ever else makes the feature removal sound at least a little logical, right? This is probably because desktop or laptop users with a common mouse that has a standard wheel with normal steps feedback are just so small minority. Thus, they can be disregarded completely - how lovely is that (especially when considering bugs 1512863 and 1512493 and a Linux platform as defined in Mozilla Bugzilla)? Sadly, it corresponds quite nicely with the current GNOME direction.

3) A huge number of comments against the removal of the feature is ignored without any explanation from GNOME developers or UI experts. This is done even though many comments provide a lot of relevant and logical reasons why it is intuitive, super useful and logical to have this feature at least available via a setting. No setting is provided and feature is removed completely in GTK 3, because the feature disabled by default via settings could cause regressions as nobody would test it. Basically: No settings guys as it is too much work (to create test cases etc.). And obviously any setting is evil as "it could be confusing to a new user" (see how useful that reason is:)?. Sadly, it too corresponds quite nicely with the current GNOME direction.

4) As a result some applications are now forced to implement the feature independently. This obviously leads to fragmentation and inconsistent UI experience not only in GNOME:(.

Thus, I really hope Firefox developers will leave this feature implemented. If one could add a negative vote to bugs 1512863 and 1512493 it would be nice - at least for the sake of standard desktop and laptop users on Linux platform as defined in Mozilla Bugzilla (where Android and other "mostly touch controlled" platforms are separated).

If many people complain about the feature, provide a setting or at least an about:config option to switch it on/off or adjust scrolling behavior such as direction. But, so far there are just two persons compared to many people who requested the feature. The only arguments I see in the removal requests are "platform consistency" or "anti desktop aka touch or smooth scroll use cases" - that is in my opinion equally weak as the "it could be confusing to a new user" reason. Why I think so? The reason is that no one using touch interface or mouse with improper wheel is forced to scroll over the tab bar in the first place. When for example I am forced by circumstances to use just the touchpad on my laptop i naturally switch tabs by clicking on them = I would not find it very intuitive to scroll over tab bar with an imprecise touch input device (same would go for using a mouse with a clumsy wheel). Thus, the point is that the feature causes no problems even on different hardware if one is not specifically trying to find or cause the problems.

To conclude this:
If you think Firefox (on Linux platform as defined in Mozilla Bugzilla) needs to be optimized more for clumsy users with improper and non-standard hardware while at the same time disregarding the needs of standard Linux desktop and laptop users with standard input devices such as a proper mouse, than Firefox should join the GNOME guys in completely removing this useful feature right after it was implemented - what a timing by the way, really sad:(.

Comment 66

[Asif Youssuff]

> The only arguments I see in the removal requests are "platform consistency" or "anti desktop aka touch or smooth scroll use cases" - that is in my opinion equally weak as the "it could be confusing to a new user" reason.

You are ignoring the "internal consistency (of doing the same thing when a tab bar is overflowing vs. not)." Either we have the same behavior for the tab bar overflowing, or we don't, but right now it is internally inconsistent. 

> The reason is that no one using touch interface or mouse with improper wheel is forced to scroll over the tab bar in the first place.

Of course not, but having something unexpected happen when that user scrolls over the tab bar isn't good, no matter if the person was "forced" to do it or not. 

> needs to be optimized more for clumsy users with improper and non-standard hardware while at the same time disregarding the needs of standard Linux desktop and laptop users with standard input devices such as a proper mouse

Not sure what you mean here - are you saying that most Firefox users are using a mouse? Where is your evidence for that?

I don't really think that is all that relevant anyway -- the internal consistency problem has not been touched by the people promoting this feature - I myself, while I prefer the non-switching behavior, would *also* prefer to not have a scrolling tab bar if this is enabled, since it is less jarring and more internally consistent. I don't know if there is a consensus around that. 

Of course, in desktop environments where this is standard, I'd be amused to know if they have the weird halfway Firefox behavior where if there are few enough tabs, tabs switch, but if there are more, they scroll - I would tend to doubt it, and if they do, I'd say that they were doing it wrong. That kind of behavior begs for some kind of keystroke modifier, since it ought not to be standard behavior (yes, for clumsy or confused users).

Comment 67

[Adrian]

As a Windows user on a reasonable large screen I don't remember the last time I had the tab bar overflow - maybe people should consider opening another window when getting THAT much tabs. Anyway, whatever floats one's boat.

Regardless of this, what I expect from the program I probably use most (right after my code editor at work) is to be convenient to use. And I don't think ANYONE with a normal mouse that has a normal scroll wheel can honestly disagree with the fact that is is extremely convenient to be able to change tabs using just the mouse wheel.

Personally I don't care much about whether it works when overflowing or not, but I'd probably be surprised to see that it doesn't since if I'm on a given tab chances are good I KNOW its surroundings. After all, who besides power users are likely to have that many tabs open at the same time?

Anyway, this whole thing would be a complete non-issue if webextensions could handle scroll events on the tab bar!

Comment 68

[Asif Youssuff]

> As a Windows user on a reasonable large screen I don't remember the last time I had the tab bar overflow

GNOME user here on a 1080p laptop. I have 152 tabs in the current window. 

> And I don't think ANYONE with a normal mouse that has a normal scroll wheel can honestly disagree with the fact that is is extremely convenient to be able to change tabs using just the mouse wheel.

I'm sure you can find someone to disagree, but that is pivoting away from the platform consistency argument. Last I saw, Windows apps don't do this. 

> Personally I don't care much about whether it works when overflowing or not, but I'd probably be surprised to see that it doesn't since if I'm on a given tab chances are good I KNOW its surroundings.

Well, that is good, since it is internally consistent. :)

> Anyway, this whole thing would be a complete non-issue if webextensions could handle scroll events on the tab bar!

Agreed, but I think a lot of users are happy this landed without being blocked by WebExtensions work. :)

Comment 69

[jmkrnet]

A reply to the comments 66 and 68 of Asif Youssuff:

I am not sure why you are seeking a strict platform consistency with regards to this issue especially on Linux platform which this bug is about. On my current Linux systems there are applications using GTK-2, GTK-3, QT-4, QT-5 and other toolkits (e.g. Java) for creating GUI. Thus, the most consistency one can get is to force a similar UI theme for all applications. Trying to achieve consistency with regards to such small behavior details of each widget in each application is probably quite unrealistic anyway (each toolkit or even a version of the same toolkit has some unique widgets and some differences in the small behavior details of similar widgets).

From a practical perspective:
- I as a user really do care about switching tabs comfortably in web browser windows where I use tabs quite heavily.

- I really do not care so much about switching tabs in other applications where I use tabs either sporadically (compared to a web browser) or not at all. Only exceptions for me are text editor (where Emacs can be configured to switch tabs via mouse scrolling exactly as I like) and file manager (where I can also switch tabs via mouse wheel scrolling as my Thunar still uses GTK-2 fortunately:). Even when the file manager switches to GTK-3 it will not be a huge problem as I usually do not have a lot of tabs in one window.

Point is a lot of people (my guess) use tabs more heavily in a web browser than in any other application and thus need to switch tabs comfortably especially in a web browser.

In a similar way it is my guess a lot of or maybe most of people on Linux who use GUI and Firefox use a desktop or laptop with a standard wheel mouse (note that Linux platform on Mozilla Bugzilla does not include "mostly touch controlled" platforms such as Android). The fact supporting my guesses is that so far it seems more people requested this feature to be implemented (for Linux and even for other platforms) and only 2 people so far seems to want to remove it. I do not have any other evidence for my guesses, but do you have any evidence for your assumption that most Linux users do not use the standard wheel mouse? What input device would you suggest Linux users mostly use (besides keyboard:), a touchpad, touch screen or some voice control like in Star Trek:D?

With regards to changes in scrolling behavior on tab bar overflow:
- I do not see it as a reason to remove this feature.

- Also as Adrian noted in comment 67 users are free to open another Firefox window when having too many tabs. Personally I still use my simple UserChrome hack which causes mouse wheel scrolling to always switch tabs, so I would be happy even if behavior would not change on overflow.

- I agree an about:config or preferences setting and/or a keyboard modifier to change the scrolling behavior especially on tab bar overflow could be a nice enhancement for this feature.

Comment 70

[Asif Youssuff]

> I am not sure why you are seeking a strict platform consistency with regards to this issue especially on Linux platform which this bug is about.

This is one of the most annoying things about using programs on Linux - the lack of consistency across apps. I like open source OSes a lot, and I care to try to achieve the type of consistency I miss from macOS. I have also seen a lot of feedback from users on macOS that care about platform consistency as well -- things like good zoom, rubber band effects on scroll, toolbar sizes, etc. Firefox is a very good program, but to be excellent, I believe that strong platform consistency is required. You may differ, and in the day of Electron apps, you may even be in the majority. Still, I pick my desktop environment for a reason, and to have an open source app that I care about not be consistent, it is disappointing. 

> Point is a lot of people (my guess) use tabs more heavily in a web browser than in any other application and thus need to switch tabs comfortably especially in a web browser.

Sure, but is that a good reason to break platform consistency? If it were a good feature, you would want it everywhere, no? And if not, why not? Is it confusing? Hard to use? If it is all upside, it should simply be standard behavior. But in the platforms targeted by Firefox - macOS, Windows - it is not. Why not? If it is desirable, why not simply advocate for this to be fixed at a platform level?

Linux is its own can of worms unfortunately, but that is why I have always defended behaviors based on the desktop environment in use *by default*, and why I am advocating for either about:config options or WebExtensions hooks to allow overrides based on user preference. 

> only 2 people so far seems to want to remove it

I am not asking to remove it, please do not misconstrue my words. I think it should follow platform consistency by default, with an override available (preferably via WebExtensions) for people who dislike the platform default. 

> but do you have any evidence for your assumption that most Linux users do not use the standard wheel mouse

I don't have any evidence either way, except to note that laptops sales outclass desktops nearly 2:1 https://www.theinquirer.net/inquirer/news/3027646/desktop-pc-sales-slumped-in-2017-as-death-rattle-sounds-once-again and that my guess is that most of those laptops spend at least a portion of their time away from a desk (and likely a mouse and external keyboard). In my own case, at home, I spend all of my time on a Linux machine *without* an external mouse. 

Desktop display resolutions are not necessarily the best picture of whether a machine is a laptop or a desktop, but per Firefox's hardware data report, https://data.firefox.com/dashboard/hardware 30% of users are on a 1366 x 768 machine - a display resolution predominantly found on laptops. On Newegg, there are 262 such displays for sale, and over a thousand in the next most common configuration (1920 x 1080). Either way, this strongly suggests that a large segment of people are running on laptops.

> I still use my simple UserChrome hack which causes mouse wheel scrolling to always switch tabs, so I would be happy even if behavior would not change on overflow

Great, it seems that most people commenting here at least, who prefer the idea of switching tabs via scroll like the idea of switching to *always* occur, as I suspected. Platform consistency notwithstanding, I also prefer this behavior because it is internally consistent, and Firefox doesn't act a different way depending on how many tabs are in the tab bar. This feels like the right default for the issue in bug 1511613 - the other platform bugs notwithstanding. Perhaps you ought to comment there, as I am not sure that developers will refer back to this ticket for guidance on that issue.

Comment 71

[jmkrnet]

A reply to the comment 70 of Asif Youssuff:

Ok, it is good to know that you do not want to remove the tab switching via mouse wheel scrolling:). Thus, basically you just want to improve the consistency of this feature behavior when tab bar overflows?

As for platform consistency - in an ideal world I would also like to have just one completely consistent GUI toolkit on Linux, but unfortunately I cannot imagine this happens any time soon:(. So I am all for consistency, but I do not require complete consistency in such details as perhaps you want to have.

As for mouse usage - I assumed a lot of Linux laptop users connect the mouse to their laptops when they have the opportunity. For example I often connect mouse even if I travel when there is at least some sort of desk to place the laptop on (usually it is more comfortable this way).

Comment 72

[Timvde]

I personally don't care about scrolling behaviour when there's no overflow (I just wouldn't use it), so I've mostly been a silent lurker. But I really wouldn't like tabs to load when I scroll my tab bar. So if that's the way this is heading, I'd really like to ask for a preference to turn it off.

Comment 73

[Adrian]

(In reply to Timvde from comment #72)
> But I really wouldn't like tabs to load when I scroll my tab bar. 

I have the feeling adding a setting whether to load or not tabs when scrolling through the list (or even without a setting) would make this whole thing **much** more complex. Switching tabs by scrolling is trivial as proven by this [1] 20-line XBL script to enable it.

But to avoid loading tabs while scrolling over them you'd suddenly need a delay that a tab needs to be active for more than X milliseconds before it starts loading (or possibly even detect how it was activated, since you'd probably want it to load immediately when clicking it). That sounds like something deeper in the C++ parts of firefox.

[1] https://forum.manjaro.org/t/howto-enable-tab-switching-in-firefox-using-mouse-wheel/39954

Comment 74

[Timvde]

> I have the feeling adding a setting whether to load or not tabs when scrolling through the list (or even without a setting) would make this whole thing **much** more complex.

Oh yes, definitely. I'm not arguing for that, but for an option to keep the current behaviour (don't change active tab, just scroll the tab bar). Sorry for being unclear.

Comment 75

[Adrian]

Ah, I hope that doesn't happen or will be behind a setting to choose whether to scroll the bar or switch tabs :p

Comment 76

[u630276]

As a casual Ubuntu user with fidgety fingers, I was quite surprised by this new behavior while I was idly scrolling my mousewheel over the tabs.

Scrolling the tab bar when tabs overflow makes sense to me, but switching tabs by using the scrollwheel when there is no overflow is definitely not what I'd expect.

I know this is just a N=1 opinion, but I would really like either a UI switch or a pref to be able to disable this feature.

Comment 77

[Mathias Panzenböck]

Another N=1 opinion: I really love that feature and can't wait for Firefox 64 to be released and integrate better into my Linux desktop.

Comment 78

[Catalin Sasca, Desktop Test Engineering [:csasca]]

The scrolling is implemented and works in Firefox Beta 65.0b8 and latest Nightly 66.0a1 (2019-01-06). Tests were performed under Ubuntu 16.04 (x64). Thanks to Sayed for verifying too.

Comment 79

[El Stellino]

Hello,

This new behaviour caught me by surprise, and it took quite a long time to figure out what was causing, let alone how to call it. Not knowing the names is a big handicap when researching for things.

My browser restarts reopening (but NOT loading) all the tabs of the previous session, and from time to time I just close them right clicking on them, not to load them. Then, from time to time, my Firefox acts strangely (and I’ve finally just discovered why), and pointing at the tab bar and scrolling no longer "highlights" the tabs, rather loads all the tab I scrolled trough. 
First of all, as a normal user, that’s rather confusing. Two behaviours with the same action.
Then, my computer is 12 years old, it’s got 4GB RAM and onboard graphics (256MB maybe?), thus loading 30 odd tabs all at once can be a rather daunting task for my machine.

However, I can now see the vast majority here wants this trivial thing, so in order not to have this feature kicking in I need to have more than 35 tabs open, at any time.

Yes, to avoid the problem I could close tabs or saving URLs in favourites, but why should I?
Why am I allowed to leave 36 unloaded tabs opened, but if I close one and scroll on the tab bar from the last one to the first, it loads automatically all the other 34, wasting precious resources that I don’t have? Is it just because Chrome does? 
[no comment]

More in detail (Comment 61, @Adrian), sometimes I open tabs to check things: for example I can open 10 tabs in one go if I am shopping on aliexpress, ebay or amazon, but then I have to work, and will check those pages later. I am a freelancer and work arrives randomly; if I am not working I browse internet, e.g. this hassle alone opened 7 tabs. Once checked, I close the relevant tabs. But, it could take several days in order to check them all, and if I am not planning to use those tabs I’d rather not loading them at all, simply because I don’t have so much memory to waste like all the people who commented here so far.
Saving amazon, ebay, aliexpress and similar URLs in the favourites? Come on…

So, I really don’t care if this “useful” feature has to be implemented, as long as there is a way to take it off somehow, either via settings, or via an about:config tweak.

I am sure that there are many users in my situation, but perhaps they don’t speak English or don’t have the education to land on here to voice their opinion, and I am also sure that these users are the most affected, as they will be using older machines that can’t handle multiple tabs open at the flick of a wheel: for this reason I think that this should be an opt‑in option, because who has resources and knowledge knows their way around; but who doesn’t, often doesn’t have resources nor knowledge or worse, both, and wouldn’t have a clue how to opt out. Always if it was possible, of course.

Comment 80

[El Stellino]

So far I solved it modifying browser.tabs.tabMinWidth to 300: I’ve got 5 pinned tabs, and it now struggles to show other 5½ in a full window. It will be very unlikely that I go below 6 tabs at any given moment, so I can flick trough on the tab bar without having to load the tabs not yet loaded.
Still, what the heck.

Comment 81

[kenneth topp]

I've been using the workaround in https://forum.manjaro.org/t/howto-enable-tab-switching-in-firefox-using-mouse-wheel/39954 for a while.

I don't understand why this setting would only apply if there is no overflow. If I'm using scroll to switch tabs setting, why wouldn't it apply 100% of the time, overflow or not?

I'm looking for a fix, since the old chrome workaround is now broken somehow.

Comment 82

[Frederick Zhang]

I'm using ArchLinux and this feature seems to be broken after upgrading to 65.0b11? Or I need any additional configurations to enable it now?

Comment 83

[Ryan VanderMeulen [:RyanVM]]

It was put behind the toolkit.tabbox.switchByScrolling pref in bug 1512493.

Comment 84

[Frederick Zhang]

Just turned it on and the feature's back into work now. Thanks Ryan :)

Comment 85

[Adrian]

Works fine on windows as well - thanks for adding the pref! :)

Comment 86

[Dmitry Gutov]

I don't understand why this setting would only apply if there is no overflow.

Same here. As soon as overflow happens, it screws with my muscle memory: why don't the tabs switch anymore? Suddenly, I have to reach for the keyboard or click with the mouse. Please add an extra pref value or something.

The only solution I've found so far is to make sure the tabs don't overflow via userChrome.css (see the discussion in https://www.reddit.com/r/firefox/comments/afh6th/howto_enable_tab_switching_in_firefox_using_mouse/). For example, by setting min-with to 10px (something that changing the relevant about:config value doesn't permit). Which is a pity because I otherwise prefer tabs overflow over Chrome's behavior. I just don't want it to stand in the way of tab switching.

Comment 87

[Marco T]

I am using the trick on https://www.reddit.com/r/firefox/comments/afh6th/howto_enable_tab_switching_in_firefox_using_mouse/ because I prefer the switch-tab-on-scroll to work in all cases, including when there is overflow. It would be great if this was implemented as a switch in the config. (Am I OT? Asking this since the title says "when it doesn't overflow", but I'd tend to keep the discussion together)

Comment 88

[eat-a-dick]

This issue prevents the addition of that feature to FoxyGestures.

https://github.com/marklieberman/foxygestures/issues/160

Before the big API change, this was already possible by another gestures add-on that does not exist any more.

From the comments I gather that the API functionality has been suspended because the scroll wheel is used to move the tab bar when it's overflowing. However, with the ability to switch tabs, one can also reach overflowing tabs that are currently hidden. And personally, I prefer to switch tabs over having an "overflow control". At the very least it should be the users choice how the scroll wheel works in the tab navigation.

Comment 89

[eat-a-dick]

Ohh, I literally just figured out that there is "toolkit.tabbox.switchByScrolling". Over two years I was missing this, I'm so happy! Nvm my previous post.