As reported on https://www.reddit.com/r/firefox/comments/e5lojt/tab_wheel_scroll_changed_in_firefox_71/

Steps to reproduce:

1. Set toolkit.tabbox.switchByScrolling to true
2. Restart Firefox (not sure this is required)
3. Open three tabs in a maximized window (doesn't need to be maximized, but the window has to be wider than the width of the tabs)
4. Hover over empty space to the right of the tabs, scroll up and down

What happens:

Nothing.

Expected result:

The same result as hovering over tabs or prior to bug 1514926

37:01.43 INFO: No more inbound revisions, bisection finished.
37:01.43 INFO: Last good revision: 94eaa02e0ea1725512893cd5139b1d200fcf4fdd
37:01.43 INFO: First bad revision: 5e221240fc1d537da612973800bbe24efa50736b
37:01.43 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=94eaa02e0ea1725512893cd5139b1d200fcf4fdd&tochange=5e221240fc1d537da612973800bbe24efa50736b

This event (https://searchfox.org/mozilla-central/rev/efdf9bb55789ea782ae3a431bda6be74a87b041e/toolkit/content/widgets/tabbox.js#463) isn't retargeting outside of the tabbrowser-tabs arrowscrollbox shadow DOM (similar to these events: https://searchfox.org/mozilla-central/rev/efdf9bb55789ea782ae3a431bda6be74a87b041e/browser/base/content/tabbrowser-tabs.js#961).

We could either listen there in the tabbrowser-tabs arrowScrollbox and dispatch the event from the Shadow DOM, or make a new function and call it from there. Though I suspect this would continue to happen if/when other components start to use SD (i.e. <tab> contents). So it seems better to switch to the standard "wheel" event instead: https://developer.mozilla.org/en-US/docs/Web/API/Element/wheel_event

Bug 1575485 was a very similar issue

Hm, switching to "wheel" has different behavior, it fires much more often so it rotates too quickly through the tabs.

Emilio, do you have any ideas here, or know who would? Basically we are currently relying on the non standard DOMMouseScroll to implement this (off by default) feature in tabs where scrolling changes the selected tab. The problem is that this event gets swallowed by the tabbrowser-tabs child arrowscrollbox's Shadow DOM (when you scroll to the right of any <tab> children), so it never fires on it.

The event is bound in the custom element at https://searchfox.org/mozilla-central/rev/efdf9bb55789ea782ae3a431bda6be74a87b041e/toolkit/content/widgets/tabbox.js#463. Switching this to "wheel" instead works but has weird behavior. Is there a way to capture the DOMMouseScroll from the parent of the shadow host?

Makes sense to be consistent with wheel.

Does the patch above fix it? (I can't build it atm, on a pretty shitty laptop).

In general, it'd be great if we used wheel and throttled it (which should be easy enough). But these events should probably be consistent with wheel.

I'll send for review if they fix the issue, otherwise I'll move to a different bug.

Updating affected flags.

Just verified this does fix it.

P3 and needs a manual preference flip to show the bug, wontfix 71.

Tell please, in which version of Firefox will this problem be fixed? I really need the tab scrolling function for any number of them.

(In reply to veron from comment #9)

Tell please, in which version of Firefox will this problem be fixed? I really need the tab scrolling function for any number of them.

The patch needs to be reviewed, then landed. That should happen pretty soon and then it'd land in Nightly. Not sure if we'd uplift the patch for 72, as it's a web-exposed change and thus there's some risk to it.

But once it lands you can use nightly which would contain the fix and would ship in FF73.

https://hg.mozilla.org/mozilla-central/rev/1fcc66338b45

AFAICT this pref is not exposed in preferences and is disabled by default.

Firefox 73 - not fixed
Why do you write that in version 73 this problem is fixed? With the mouse wheel, the tabs scroll only visible, when it goes abroad, the tabs are not selected through the mouse wheel.