Bugzilla

Assignee

Comment 2

•

1 year ago

(In reply to somerandomjohndoe from comment #0)

Steps to reproduce

Ensure that general.smoothScroll is set to false.

Open 50 tabs (or more, depending on Firefox's window width) with Ctrl+T or by repeatedly clicking the tab strip's + button to allow the tab scroller to appear and provide sufficient space to scroll.

Click any tab (preferably the middle one for better visibility) and scroll the mouse wheel.

Expected result

Tabs scroll into and out of view, allowing the user to observe their displacement over time.

This can still be simulated by setting general.smoothScroll to true, however all page content will then be subject to smooth scrolling as well.

Actual result

Tabs instantly warp to their final positions, which can be confusing if the user has many tabs that look similar (same favicon, similar titles) given the significant displacement.

This is particularly acute when the currently selected tab is scrolled out of view, since that sole distinguishing visual marker is no longer visible.

I tested on macOS and windows, and I see that the tab scroll happens much quicker and is not animated, but I still see visual markers indicating the location in the tab list. I may be misunderstanding what you mean by the visual marker. Do you happen to have a screen recording of the expected and bad behavior?

Notes

In Windows Performance Options (%SystemRoot%\System32\SystemPropertiesPerformance.exe), the Animate controls and elements inside windows checkbox is ticked.

The ui.prefersReducedMotion hidden preference is not set.

I filed this bug in the Layout: Scrolling and Overflow component since that was also where the (suspected) regressing commit's bug was filed; please relocate this bug if it is incorrect.

I set Platform (Operating System) to Windows since I did not test on other platforms.

Thank you for your time.

Thanks you for the bug report and the detailed info you provided!

Comment 3

•

1 year ago

Maybe this is specific on Windows with a certain type of mouse or a certain system setting? If Windows sends SB_PAGEDOWN in each wheel event, we do multiply the scroll amount, thus it looks as if it's wrapping?

BugBot [:suhaib / :marco/ :calixte]

Assignee

Comment 4

•

1 year ago

(In reply to somerandomjohndoe from comment #0)

Notes

In Windows Performance Options (%SystemRoot%\System32\SystemPropertiesPerformance.exe), the Animate controls and elements inside windows checkbox is ticked.

The ui.prefersReducedMotion hidden preference is not set.

I filed this bug in the Layout: Scrolling and Overflow component since that was also where the (suspected) regressing commit's bug was filed; please relocate this bug if it is incorrect.

I set Platform (Operating System) to Windows since I did not test on other platforms.

Do you happen to know if you have your system configured to scroll "multiple lines at a time" or "one screen at a time" on mouse wheel scroll?

Flags: needinfo?(drobertson) → needinfo?(spamyourwhateverhere)

Kestrel

Comment 5

•

1 year ago

The main issue is that toolkit.scrollbox.smoothScroll is no longer being honored, the tab bar is meant to have smooth scrolling independent of general.smoothScroll.

Status: UNCONFIRMED → NEW

status-firefox112: --- → wontfix

status-firefox113: --- → affected

status-firefox114: --- → affected

Ever confirmed: true

Summary: Tabstrip scrolling animation breaks when general.smoothScroll is false → Tabstrip scrolling animation breaks when general.smoothScroll is false (does not honor toolkit.scrollbox.smoothScroll)

Comment 6

•

1 year ago

Set release status flags based on info from the regressing bug 1743045

status-firefox-esr102: --- → unaffected

Ryan VanderMeulen [:RyanVM]

Updated

•

1 year ago

status-firefox113: affected → fix-optional

Joseph C. Sible

Comment 7

•

1 year ago

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)

Maybe this is specific on Windows with a certain type of mouse or a certain system setting? If Windows sends SB_PAGEDOWN in each wheel event, we do multiply the scroll amount, thus it looks as if it's wrapping?

I just ran into this bug on Linux, so it's definitely not specific to anything about Windows.

Assignee

Updated

•

1 year ago

Severity: -- → S2

Assignee

Updated

•

1 year ago

Severity: S2 → S3

Assignee

Comment 8

•

1 year ago

Set to S3 since this seems to be an annoyance instead of a usability issue. Please let me know if I'm mistaken.

Comment 9

•

1 year ago

•

Edited

Attached video screencast of bug with default config vs. with pref flipped — Details

I can reproduce on Linux, too, FWIW. Here's a screencast of me mousewheel-scrolling the tabstrip in:
(1) fresh profile
(2) fresh profile where I have (previously) set general.smoothScroll set to false and restarted Firefox.

In both cases, I have the same list of open tabs, which are about:config plus 18 tabs from going Bookmarks | Firefox Nightly Resources | Open All in Tabs 3 times. (That bookmarks submenu has 6 pages in it, so 3x open-all-in-tabs gives me 18 tabs.)

In the profile where I have general.smoothScroll set to false (around 0:08 and later in the screencast) the tabstrip-scrolling is hard to visually track due to the instant jumping of tabs from one place to another. (This is in a case where none of the adjacent tabs have the same favicon/title; this would obviously be even more harder-to-follow if you had a bunch of adjacent tabs that look similar.)

Comment 10

•

1 year ago

Attached video screencast showing that arrow buttons on left/right side of the tabstrip *are* controlled by `toolkit.scrollbox.smoothScroll` pref — Details

Interestingly, the clickable arrow buttons on either side of the tab-strip do still seem to be governed by toolkit.scrollbox.smoothScroll (as-expected).

Here's a screencast which starts with a fresh profile where I've set general.smoothScroll set to false. Mousewheel scrolling jumps instantly (unexpected I think, per this bug) but the tabstrip's arrow buttons do smooth-scrolling (as-expected I think).

Halfway through the screencast, I toggle toolkit.scrollbox.smoothScroll to false and restart Firefox, and that makes the arrow buttons start doing "jump instantly" type scrolling.

Comment 11

•

1 year ago

•

Edited

One other type of scrolling that I just tested, but didn't bother capturing in a screencast: you can "scroll" from one extreme to the other, by using the v dropdown-button at the right edge of the tabstrip to toggle between the very-first vs. very-last tab. That start-to-end scrolling seems to behave the same as mousewheel scrolling -- it plays an animation in the default configuration, vs. jumps immediately if I set general.smoothScroll to false and restart Firefox. And that's probably wrong; I suspect it should be smooth unless toolkit.scrollbox.smoothScroll is disabled, per comment 5.

Comment 12

•

1 year ago

(In reply to Daniel Holbert [:dholbert] from comment #11)

One other type of scrolling that I just tested, but didn't bother capturing in a screencast: you can "scroll" from one extreme to the other, by using the v dropdown-button at the right edge of the tabstrip to toggle between the very-first vs. very-last tab. That start-to-end scrolling seems to behave the same as mousewheel scrolling -- it plays an animation in the default configuration, vs. jumps immediately if I set general.smoothScroll to false and restart Firefox. And that's probably wrong; I suspect it should be smooth unless toolkit.scrollbox.smoothScroll is disabled, per comment 5.

Thank you Daniel. This is a great scenario to see this bug. I was initially thinking that normal wheel transactions just jump to a tab which was originally in view so that I didn't see jumps to tabs outside the viewport originally.

Anyways, given that the option general.smoothScroll=false should stop any smooth scroll, it makes me wonder what the best behavior for people who are suffering from motion (i.e. motion sickness) is?

For normal wheel transaction reducing scroll distance would help?
For the scrolling from drop-button menu there's nothing we can do because the user knows the exact destination?

Comment 13

•

1 year ago

(In reply to Hiroyuki Ikezoe (:hiro) from comment #12)

Anyways, given that the option general.smoothScroll=false should stop any smooth scroll, it makes me wonder what the best behavior for people who are suffering from motion (i.e. motion sickness) is?

If we take that mindset (which sounds reasonable to me), that suggests that the left/right arrows at the right side of the tab strip should change to respect general.smoothScroll=false. (They don't right now, per comment 10.) Not sure if we should spin off a bug for that vs. fix that here.

For normal wheel transaction reducing scroll distance would help?

Yeah, that might be worth trying. Adding user-expectation weight to that -- in comment 0, it sounds like the reporter wasn't so-much requesting that the animation become smooth, but just noticing that (now that we've made it not-smooth, respecting this pref) that our not-smooth-scrolling for the tabstrip happens to be hard to follow. With smaller scroll-increments, I think it'd be easier to follow the progress of tabs as they move to the sides, and that would address this user pain point.

It might be worth picking a "scroll-tick distance" less than 50% of a tab width (e.g. maybe 40%?), so that if you have a sea of identical-looking tabs, you can visually see/feel a "nudge" in the correct direction when you mousewheel-scroll. (If we were to pick precisely 50%, then -- with a sea of identical-looking tabs -- a mousewheel-scroll up and down would look exactly the same).

For the scrolling from drop-button menu there's nothing we can do because the user knows the exact destination?

That's fair; the animation in that scenario is a "flourish" more than a usability necessity.

Comment 14

•

1 year ago

Canceling the comment 4 needinfo since I suspect we've moved past it. (Though: Dan, feel free to restore it if you're still curious about it. :))

Flags: needinfo?(spamyourwhateverhere)

vz

Comment 15

•

1 year ago

Affected by the bug since upgrade to FF 112 under Linux (Kubuntu).
Tab scrolling is just too jerky now. Setting "Smooth Scrolling" setting fixes the issue, but as others - I do not like smooth scrolling for websites.
Hopefully the behavior will be restored.

Pascal Chevrel:pascalc (PTO until April 26)

Comment 16

•

1 year ago

Okay there are three things we need to fix/change.

Honor toolkit.scrollbox.smoothScroll in tab scrolling code (I am not sure whether there's some other components we need to honer the pref)
Respect general.smoothScroll for tab scrolling by clicking left/right arrow
Reduce the wheel scroll distance

Jurtaani

Comment 17

•

1 year ago

as a end user may i offer my idea how to fix this issue.
so currently there is only one ui toggle for smooth scrolling which used to toggle it on/off on websites but let the tab bar alone.
now since Firefox 112 it also controls tab bar scrolling and makes it hard/impossible to use tabs with smooth scrolling disabled.

while tab scrolling behavior in smooth scrolling disabled, should be made more usable. I would also like to see toggle next to the current smooth scrolling option that would only toggle smooth scrolling on/off on the tab bar.
to avoid too many confusions on users, link the current smooth scrolling toggle to control both smooth scrolling options on/off. but let the tab bar one to be individually turned on/off without affecting the general smooth scrolling option.

this way if user wants all scrolling to be smooth, then they just have to toggle the current option on. but if they are like me and do not like smooth scrolling on websites at all, but want/need it to be there for the tabs. then they can just click on the "smooth scrolling for tabs" option and then they would have websites without this nauseating smooth scrolling. but still have the option to see what they are doing on tabs regardless of the state of the website smooth scrolling option.

Kestrel

Comment 18

•

11 months ago

A workaround is to leave general.smoothScroll = true and instead change general.smoothScroll.mouseWheel = false which does not affect the tab strip.

Comment 19

•

11 months ago

(In reply to Hiroyuki Ikezoe (:hiro) from comment #16)

Okay there are three things we need to fix/change.

Honor toolkit.scrollbox.smoothScroll in tab scrolling code (I am not sure whether there's some other components we need to honer the pref)

Respect general.smoothScroll for tab scrolling by clicking left/right arrow

Reduce the wheel scroll distance

Hiro, is there something planned short term for 114 / 115? Thanks

Flags: needinfo?(hikezoe.birchill)

Pascal Chevrel:pascalc (PTO until April 26)

Assignee

Comment 20

•

11 months ago

(In reply to Pascal Chevrel:pascalc from comment #19)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #16)

Okay there are three things we need to fix/change.

Honor toolkit.scrollbox.smoothScroll in tab scrolling code (I am not sure whether there's some other components we need to honer the pref)

Respect general.smoothScroll for tab scrolling by clicking left/right arrow

Reduce the wheel scroll distance

Hiro, is there something planned short term for 114 / 115? Thanks

We have this tracked in our current sprint, but may defer until our upcomming sprint. If you feel that does not reflect the severity of the issue, let me know and I'll bring it up in our next APZ planning meeting.

Flags: needinfo?(hikezoe.birchill)

Updated

•

11 months ago

status-firefox113: fix-optional → wontfix

status-firefox114: affected → fix-optional

status-firefox115: --- → affected

Donal Meehan [:dmeehan]

Updated

•

11 months ago

status-firefox114: fix-optional → wontfix

status-firefox115: affected → wontfix

status-firefox116: --- → affected

Assignee

Comment 21

•

10 months ago

After doing a little bit of digging through history it looks like toolkit.scrollbox.smoothScroll has never impacted the smoothness of a user-gesture tabstrip scroll (e.g. a mousewheel scroll). Is this something we'd want to introduce? If we were to introduce something like this, I'm not sure how it could be tabstrip-only... We could add something like browser.chrome.smoothScroll that impacts all smooth scrolls originating from the browser chrome, such that a smooth scroll from the browser chrome is always respected. The tabstrip just relies on a scroll with behavior set for wheel scrolls. See MozArrowScrollbox.on_wheel instant variable and the implementation of MozArrowScrollbox.scrollByPixels.

toolkit.scrollbox.smoothScroll only impacts the smoothness of the arrow buttons as seen in comment 10 (See the use of MozArrowScrollbox._arrowScrollAnim for details. Essentially, toolkit.scrollbox.smoothScroll only dictates that we should start an animation here which should only happen on arrow mousclicks. The implementation of this is quite different from that of other smooth scrolls, so perhaps this should also be default disabled if the system setting prefers-reduced-motion is set, instead of also disabled by general.smoothScroll?

Kestrel

Comment 22

•

10 months ago

(In reply to Dan Robertson (:dlrobertson) from comment #21)

toolkit.scrollbox.smoothScroll has never impacted the smoothness of a user-gesture tabstrip scroll (e.g. a mousewheel scroll).

That's strange since it definitely affects mousewheel smoothness for me from Firefox 4 up until Firefox 112 on Ubuntu 23.04, independent of general.smoothScroll.

general.smoothScroll = false
toolkit.scrollbox.smoothScroll = true
Tab strip mousewheel scrolling is smooth.

general.smoothScroll = true
toolkit.scrollbox.smoothScroll = false
Tab strip mousewheel scrolling is not smooth.

Assignee

Comment 23

•

10 months ago

(In reply to Kestrel from comment #22)

(In reply to Dan Robertson (:dlrobertson) from comment #21)

toolkit.scrollbox.smoothScroll has never impacted the smoothness of a user-gesture tabstrip scroll (e.g. a mousewheel scroll).

That's strange since it definitely affects mousewheel smoothness for me from Firefox 4 up until Firefox 112 on Ubuntu 23.04, independent of general.smoothScroll.

Maybe the "auto" behavior here gets evaluated to "smooth" due to inheriting smoothscroll, which would specify the default scroll behavior here. Note that this would mean that prefers-reduced-motion is already handled.