|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
59 bytes, text/x-review-board-request
|Details | Review|
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 !
Enhancement/feature request I see this feature of Chrome on Linux but not on Windows.
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.
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.
I meant "We can make this feature optional anyway"
(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.
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.
(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.
(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?
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.
Nothing more than pressing Ctrl + Tab...
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.
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.
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)?
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. :)
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.
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. :(