Starting with the 20160419 nightly, the number of pixels the tab strip scrolls have greatly increased. The only way the mitigate the change is to decrease the number of lines per scroll in Windows or change mousewheel.default.delta_multiplier_y, which both have obvious negative consequences elsewhere. I expect this is a result of Bug 1263975, as it seems like the most likely candidate from the list of changes from the mozillazine daily thread.

The way it works now is: If your setting is "scroll by N lines", then the tab strip will scroll by N *tabs* on each scroll. It sounds like this is too fast. What behavior would you prefer? The Windows setting "scroll by one screen at a time" is not handled correctly by the tab strip now. (It's handled as "scroll by one tab".) I'll need to fix that.

I'm guessing your question was aimed at me. I currently have windows set to scroll 4 lines at a time (and thus apparently 4 tabs at a time), which makes it very easy to scroll past whatever tab I'm looking for (as you correctly guessed). I'm not sure how people that have windows set to scroll a large numbers of lines would find anything in the tab strip. I'm not entirely sure what the previous behavior was, but one tab at a time would be fine with me. Maybe I'm in the minority with liking scrolling of things to be fairly slow.

Hmm, I don't actually see any difference in behavior when it comes to wheel line scrolling the tab bar, compared to what we did before. I've set the Windows pref to "scroll 5 lines at a time" and the tab strip ends up scrolling 5 tabs at a time in Firefox 46 Beta. Masayuki, do you know in what cases the DOMMouseScroll detail value might be different from the DOM_DELTA_LINE wheel deltaY value?

(In reply to Markus Stange [:mstange] from comment #3) > Hmm, I don't actually see any difference in behavior when it comes to wheel > line scrolling the tab bar, compared to what we did before. I've set the > Windows pref to "scroll 5 lines at a time" and the tab strip ends up > scrolling 5 tabs at a time in Firefox 46 Beta. > > Masayuki, do you know in what cases the DOMMouseScroll detail value might be > different from the DOM_DELTA_LINE wheel deltaY value? deltaY may be less than 1 or lager than -1 if the mouse supports high resolution scroll (e.g., 0.2 line is scrolled per wheel event). https://dxr.mozilla.org/mozilla-central/rev/fc15477ce628599519cb0055f52cc195d640dc94/toolkit/content/widgets/scrollbox.xml#318,337 Looks like that scrollByIndex() supports only integer delta value. So, there are some possible approaches: 1. Making related code float delta value aware. 2. Adding new chrome only attributes to WheelEvent such as |lineOrPageDeltaX| and |lineOrPageDeltaY| and use it at handling wheel event on tab bar.

Hopefully not to add noise to this bug, but I tried out the current release version of Firefox over the weekend. With an old profile it had the slow scrolling in the tab bar, but with a brand new profile it had the faster scrolling. I then looked to see if there was some kind of about:config differences, but did not see any. Turns out, even though it does not have any setting that specifically control the number of pixels/tabs scrolled, Tab Mix Plus was causing the slower scrolling for some reason. That's my fault. I should've done more testing with other versions of Fx and new profiles.

Thanks for checking, John! So since we haven't actually regressed anything here, I'm going to close this bug as INVALID. I'll open a new bug to make scrollByIndex handle fractional values for high resolution mice on Windows. If somebody feels strongly about the tab scroll speed being to fast, they are welcome to open a new bug that is not tracked as a regression.

(In reply to Markus Stange [:mstange] from comment #1) > The Windows setting "scroll by one screen at a time" is not handled correctly by the tab strip now Once correction: it was NEVER handled correctly. Not now, not before.