Scrolling the mouse wheel over the tabs does not switch tabs

[David Prieto]

Binary package hint: firefox-3.0

In every gnome app, scrolling up or down the mouse wheel changes the active tab. In Firefox this does not work, which detracts from integration.

[Vhaarr+bmo (vhaarr+bmo)]

Created an attachment (id=173475)
version 0.1

First version

[Mike Connor (mconnor)]

(From update of attachment 173475)
Making this global isn't right, still thinking about whether we should limit to
>= gtk2.6 or not.

[Vhaarr+bmo (vhaarr+bmo)]

mconnor: How would we do that ?

[Peter-vanderwoude (peter-vanderwoude)]

together with drag&drop tabs (FF1.5) it would nicely finish the taboptions.

10+ tabs squeezed on the tabbar results in poor readability/usability this
bug would be a major improvement.

(I'd personally love to se this for all OS)

[Peter-vanderwoude (peter-vanderwoude)]

my bad
forget my comment, I misread the bug

[Bugs-caleb (bugs-caleb)]

*** Bug 250861 has been marked as a duplicate of this bug. ***

[Martijn-martijn (martijn-martijn)]

Created an attachment (id=194094)
version 0.2

Based on version 0.1
I have no idea how to make it >= gtk2.6 only.

[Dtownsend (dtownsend)]

*** Bug 308002 has been marked as a duplicate of this bug. ***

[Vhaarr+bmo (vhaarr+bmo)]

Maybe we can use PR_FindFunctionSymbolAndLibrary or PR_FindSymbolAndLibrary and
lookup something GTK2.6 specific? I'm not sure what that would be though, but
here is a list of new symbols in GTK2.6: <http://www.gtk.org/api/2.6/gtk/ix05.html>.

Of course, this would require some C code as well as JS. In any case, I think we
should add a pref here:
'browser.tabs.mouseScrollChangesTab'
    0: Off.
    1: On.
    2: Behave according to platform.
Where 2 is default. If we don't add it here, we're sure to get an RFE for it
sooner or later anyway.

mconnor, think this could work? Where would we put the required C code for this?

[Vhaarr+bmo (vhaarr+bmo)]

Here is code that checks for GTK2.4, for reference:
<http://lxr.mozilla.org/mozilla/source/widget/src/gtk2/nsFilePicker.cpp#153>
(LoadSymbolsGTK24()).

[Vhaarr+bmo (vhaarr+bmo)]

Maybe we could (ahem) add a method like "GetToolkitVersion(out ACString
version)" to nsIToolkit ... :-P
Then we'd have to get a pointer to the current nsIToolkit implementation in JS
anyway, and I'm not sure it's exposed at all?

roc: Got a more sensible idea?

[Roc-ocallahan (roc-ocallahan)]

How about we just have an on/off pref and set it in platform-specific #ifdefs?
Would anyone really object to turning this on for all GTK versions?

[Garsh (garsh)]

Please be aware that this enhancement conflicts with Bug 194696 and possibly Bug
270101.

[Vseerror (vseerror)]

Is bug or fix linux only?
Does it also fix Bug 220397

[Moz-jomel (moz-jomel)]

(In reply to comment #14)
> Is bug or fix linux only?
No, hence OS:All. And I've successfully tested the patch on Windows.

> Does it also fix Bug 220397
No, quite the contrary, it causes different behaviour to that requested by bug
220397. If (when) this is fixed then we should wontfix 220397 since it would be
confusing and non-intuitive for the close button to behave differently from the
rest of the tabbar (plus switching tabs while the mouse is over the close button
is useful).

[Vseerror (vseerror)]

(In reply to comment #15)
> > Does it also fix Bug 220397
> No, quite the contrary, it causes different behaviour to that requested by bug
> 220397.

So, it only scrolls tabs when mouse is actually over a tab - it doesn't permit
the entire tabbar?

>If (when) this is fixed then we should wontfix 220397 since it would be
> confusing and non-intuitive for the close button to behave differently from the
> rest of the tabbar

I don't agree that this is a given. See below.

> plus switching tabs while the mouse is over the close button is useful.

personally I agree ... but it apparently depends on the user's perspective.

If main objective is decide which tab to close while scrolling through tabs ->
should allow scroll tabs over close button
If main objective is read a tab (and scroll the contents to help decide) if one
is done with it -> should allow scroll of page (not tabs) while over close button

[Vhaarr+bmo (vhaarr+bmo)]

Created an attachment (id=195874)
version 0.3

Like roc suggested in comment 12. As I remember it, mconnor wasn't decided on
whether it should be enabled for all GTK versions or not, like this patch does.

[Moz-jomel (moz-jomel)]

(In reply to comment #16)
> So, it only scrolls tabs when mouse is actually over a tab - it doesn't permit
> the entire tabbar?
No, it scrolls between tabs as long as the mouse is anywhere on the tab bar
(including the close button).

> > plus switching tabs while the mouse is over the close button is useful.
> personally I agree ... but it apparently depends on the user's perspective. [etc.]
Sure, but as both behaviours can be useful and one (close button behaves like
rest of tab bar) is fairly consistent, while one (close button does its own
thing and scrolls page) is unexpected, we may as well keep the interface
consistent. (bug 308215 is a different matter however and needs proper debate).

[Moz-jomel (moz-jomel)]

Surely we can get a simple but useful change like this in for 2.0, especially since the UI is one of the focuses of that release?

[Ventnor-bugzilla (ventnor-bugzilla)]

Is the GTK version issue still a problem for Trunk? I'd like to make an updated fix for this.

[NW (northwest)]

If you have more tabs open than fit on the bar, it would be nice to be able to scroll to see other available tabs without switching through all of them in turn, like it currently does. Switching one by one would probably be glacial if any of the tabs is new, complex, and has to be drawn for the first time, too.

[Reed Loden (reed)]

*** Bug 410213 has been marked as a duplicate of this bug. ***

[Lars Strojny (lars-strojny)]

Are there plans to fix that in the upcoming 3.0 release?

[Reed Loden (reed)]

*** Bug 410401 has been marked as a duplicate of this bug. ***

[Jakub 'Livio' Rusinek (liviopl-pl)]

#Nik Wegner, what about integration with GTK? Firefox tries to emulate GTK in the best way possible, so why it shouldn't behave like usual GTK app?

[NW (northwest)]

>what about integration with GTK?
This bug is marked OS:All. Maybe if you change it to OS:GNU you could fix it like that.

[Jakub 'Livio' Rusinek (liviopl-pl)]

I want it to be integrated as well as possible.

[Reed Loden (reed)]

*** Bug 417427 has been marked as a duplicate of this bug. ***

[Reed Loden (reed)]

*** Bug 419407 has been marked as a duplicate of this bug. ***

[Reed Loden (reed)]

*** Bug 420567 has been marked as a duplicate of this bug. ***

[David Prieto (frandavid100-gmail)]

Binary package hint: firefox-3.0

In every gnome app, scrolling up or down the mouse wheel changes the active tab. In Firefox this does not work, which detracts from integration.

[Murat Gunes (mgunes)]

Thanks for reporting.

[Dtownsend (dtownsend)]

*** Bug 426323 has been marked as a duplicate of this bug. ***

[Vytautas Jakutis (vytautas)]

I think firefox on linux, as an app that uses GTK widgets, should look and feel like all GTK apps, so this scrolling must be implemented before the final 3.0 release.

[Mike Connor (mconnor)]

(From update of attachment 195874)
Michael, if you want to do a new patch, I'll review. This patch is well and truly obsolete now.

[Jh-junetz (jh-junetz)]

(In reply to comment #20)
> Is the GTK version issue still a problem for Trunk? I'd like to make an updated
> fix for this.

The FF3 requirements page <http://www.mozilla.com/en-US/firefox/system-requirements.html> says GTK+ 2.10 or higher is required so this shouldn't be a concern anymore.

Given that SeaMonkey is also using Toolkit's tabbox.xml nowadays I'd love to see this fixed with a pref. That would allow us to fix bug 409792 by simply activating the feature for all platforms in SeaMonkey's default prefs file (in addition to porting the browser.js changes of course).

The only concern I have is that FF is already using the mouse wheel on the tab bar for scrolling through it when there are very many open tabs. SeaMonkey doesn't have that yet so it's currently not a concern for the suite.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/200601

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:
https://bugzilla.mozilla.org/show_bug.cgi?id=281192

[Dao (dao)]

Created an attachment (id=394356)
patch

[Dao (dao)]

Created an attachment (id=394362)
patch v2

The event needs to be handled in the tabs binding, not the tabbox binding. Also, changing the scrollbox handler to phase="capturing" was unnecessary.

[Jh-junetz (jh-junetz)]

The proposed patch only enables the functionality for GTK2 which is probably fine for FF but since it's shared (Toolkit) code and other applications may (actually: will, see comment 34) want to enable it unconditionally, is there a way to leave a backdoor open? If not with a pref, maybe with a symbol that would need to be defined by applications that want it that way? As far as I understand MDC, checking against a certain application (e.g. MOZ_SUITE) is discouraged so I'd suggest to check for the desire to have the feature instead.

[Mike Connor (mconnor)]

How does this interact with the established behaviour of scrolling the tabstrip when we're overflowing?

[Dao (dao)]

When overflowed, the scrollbox consumes the event so that it won't reach the tabs binding.

[Mike Connor (mconnor)]

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...

[Dao (dao)]

Then again, not supporting it at all in tabbrowser also breaks that model, just at a different level.
I agree that the mixture is strange, but I'm not sure that the alternatives are better.

[Dao (dao)]

Created an attachment (id=394634)
patch v2b

this excludes the tabbrowser tabbar

[Mike Connor (mconnor)]

(From update of attachment 394634)
I think we should just do this, and not muck with the tabbrowser interaction model at this time.

[Dao (dao)]

http://hg.mozilla.org/mozilla-central/rev/4f3e5df9b2cd

[Mail-majkl578 (mail-majkl578)]

I'm wondering how long you are able to speak about one bug...

Unfortunately this still does not work in nightly version of Firefox 4.0 (Mozilla/5.0 (X11; Linux i686; rv:2.0b3pre) Gecko/20100723 Minefield/4.0b3pre). Scrolling over tabs does not have any effect.

[Micah Gersten (micahg)]

This is fixed in Natty in Firefox 4.0b7. Please report any other issues you may find.

[robket (robket)]

Unfortunately this bug still appears to be present in Natty Beta1 (Firefox 4.0~rc2+build3+nobinonly-0ubuntu2)
Scrolling the mouse wheel over the tabs does nothing.