1512863 - Tab switching by scrolling conflicts with non-discrete mousewheels, touchpad diagonal scrolling and natural scrolling

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect, P5)

Description

[Kestrel]

Switching tabs by scrolling (Bug 1285812) was removed from GtkNotebook in GTK3[1] and this behavior no longer exists for tabs in GNOME (nautilus, terminal, gedit, epiphany etc.). There are several reasons mentioned in this and a followup bug report[2] summarized here.

1. Mousewheels with low scroll resistance and/or no discrete steps cause unwanted and difficult to control tab switching.

2. Tab switching responds to both vertical and horizontal scrolling, so on touchpads when scrolling in the up+right or down+left direction it causes tabs to switch backwards and forwards rapidly, unreliably or not at all.

3. Natural scrolling reverses the scroll direction, "moves the content, not the view", which makes sense for scrolling a page but not for tab switching. When this is enabled the tab switch direction is opposite to what is expected.


[1] https://bugzilla.gnome.org/show_bug.cgi?id=630226
[2] https://bugzilla.gnome.org/show_bug.cgi?id=793824

Comment 1

[Adrian]

(1) sounds like a perfect justification for an about:config option
(2) probably as well
(3) make the direction configurable (e.g. 0/1/-1 in about:config for disabled/normal/reverse)

Comment 2

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

Aaron, can you take a look at this bug as well as bug 1285812 to see if we should go forward with shipping this behavior change?

Comment 3

[Andrew Overholt [:overholt]]

Martin, can you or someone who's aware of the Gtk3 scroll / tab switch situation weigh in here with what Firefox should do?

Comment 4

[Martin Stránský [:stransky] (ni? me)]

(In reply to Andrew Overholt [:overholt] from comment #3)
> Martin, can you or someone who's aware of the Gtk3 scroll / tab switch
> situation weigh in here with what Firefox should do?

I think we should ask what's expected by users here.
If Chrome has this feature and works fine there we should also support that.
We may also add a pref to enable users to turn it off.

(In reply to Kestrel from comment #0)
> Switching tabs by scrolling (Bug 1285812) was removed from GtkNotebook in
> GTK3[1] and this behavior no longer exists for tabs in GNOME (nautilus,
> terminal, gedit, epiphany etc.). There are several reasons mentioned in this
> and a followup bug report[2] summarized here.
> 
> 1. Mousewheels with low scroll resistance and/or no discrete steps cause
> unwanted and difficult to control tab switching.

That's IMHO disabled for Firefox as we don't use XINPUT2. May affect Wayland backend.

> 2. Tab switching responds to both vertical and horizontal scrolling, so on
> touchpads when scrolling in the up+right or down+left direction it causes
> tabs to switch backwards and forwards rapidly, unreliably or not at all.
> 
> 3. Natural scrolling reverses the scroll direction, "moves the content, not
> the view", which makes sense for scrolling a page but not for tab switching.
> When this is enabled the tab switch direction is opposite to what is
> expected.

Yes, that may be an annoyance. Do we know how Chrome handles that?

Comment 5

[Martin Stránský [:stransky] (ni? me)]

(In reply to Martin Stránský [:stransky] from comment #4)
> > 2. Tab switching responds to both vertical and horizontal scrolling, so on
> > touchpads when scrolling in the up+right or down+left direction it causes
> > tabs to switch backwards and forwards rapidly, unreliably or not at all.

Yes, I see that on Chrome too. I confirm that switching the tabs with
touchpad is very sensitive (on both Chrome and Firefox).

> > 3. Natural scrolling reverses the scroll direction, "moves the content, not
> > the view", which makes sense for scrolling a page but not for tab switching.
> > When this is enabled the tab switch direction is opposite to what is
> > expected.

Yes. But it can be disabled in Settings, it's "Natural scrolling" preference.

> (In reply to Andrew Overholt [:overholt] from comment #3)
> > Martin, can you or someone who's aware of the Gtk3 scroll / tab switch
> > situation weigh in here with what Firefox should do?
> 
> I think we should ask what's expected by users here.
> If Chrome has this feature and works fine there we should also support that.
> We may also add a pref to enable users to turn it off.

From my testing the Firefox 65 behaves the same way as Chromium.

I also have feedback from a chrome user who is missing this feature at Firefox
even with the possible drawbacks.

Comment 6

[Dão Gottwald [:dao]]

Given the above comments, I don't think we need to track this.

Comment 7

[Kestrel]

Tab switching is nice to have as an option for Chromium parity but should not be forced on users like it is currently, given the issues mentioned. Chromium has all the same problems but it is now a legacy feature where the circumstances have changed considerably since its introduction.

MOZ_USE_XINPUT2=1 causes tab switching to be even more sensitive and is borderline broken. Fedora apparently uses this by default so it cannot be so easily disregarded. There are also many online guides that recommend enabling it to get pixel scrolling which is becoming increasingly desirable.

Even without XINPUT2, a continuous input device like a touchpad is not well-suited for discrete switching, as it gives no feedback until after the switch happens, making it very mistake prone. For normal scrolling this is fine since a small position deviation is not a big deal but switching to the wrong tab gives a very different result and triggers a lot of unnecessary activity.

The Natural Scrolling conflict can of course be worked around by simply disabling it, but sacrificing such fundamental system-wide scrolling behavior for one application is a big ask. It is more likely that users will just learn to deal with the backwards tab switching in Firefox.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

This feature is off by default across all affected versions now.

Comment 10

[:Gijs (he/him)]

This was disabled by default in bug 1512493 but is still available behind a pref so I don't think there's anything left to do here.