1714143 - Elastic overscroll effect is disabled by the "Reduced Motion" system setting

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P3)

Description

[steve]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

macOS 11.4

For unknown reasons elastic overscrolling is straight up not happing on my mac in both Firefox 89 or nightly.

Tests done with internal and external track pad on 2017 MacBook Pro.

Tried new profile, problem unchanged.

defaults read -g NSScrollViewRubberbanding
results in

defaults read -g NSScrollViewRubberbanding 
2021-06-02 13:18:29.586 defaults[29072:1800351] 
The domain/default pair of (kCFPreferencesAnyApplication, NSScrollViewRubberbanding) does not exist

WEBRENDER_COMPOSITOR - available by default
Asynchrones Wischen und Zoomen - Mausrad-Eingabe aktiviert; Ziehen der Bildlaufleiste aktiviert; Tastatur aktiviert; automatischer Bildlauf aktiviert; sanftes Zoomen durch Antippen aktiviert

Actual results:

Elastic overscrolling not happening

Expected results:

Firefox 89+ should support elastic overscrolling

Comment 1

[Botond Ballo [:botond]]

Could you check that in about:config, apz.overscroll.enabled is set to true?

Comment 2

[steve]

Forgot to mention that: apz.overscroll.enabled: true

Comment 3

[Botond Ballo [:botond]]

Could you try the following please:

• Start Firefox from a terminal.
• Go to about:config, add an integer-valued pref named logging.apz.controller with the value 4. This should cause log messages to be displayed in the terminal.
• Load any scrollable website and perform a touchpad scroll gesture that you would expect to cause overscroll.
• Post the logs from the terminal in an attachment to this bug.

Thanks!

Comment 4

[steve]

https://bin.disroot.org/?83d681c9b45d29d2#63j1mUpkshDa2ZTSxvQ7q2PrUfGfyWZ46ChBTNDAJnd6 (1 year)
Hope this helps, thanks for looking into this.

Comment 5

[Botond Ballo [:botond]]

Thanks. Some of what I'm seeing in the logs looks encouraging ("taking overscroll while panning"), and seems like that should be accompanied by a visual overscroll effect. But then there are other things that seem unexpected, like "changing from state 6 to 0" shortly after momentum scrolling starts. I'm also never seeing the page enter the OVERSCROLL_ANIMATION state (state 9), which could be related to the previous point.

So, not quite sure what's going on here yet.

A couple of questions to rule out some possibilities:

• Does this issue affect all scrollable pages, or just specific ones?
• Does disabling WebRender, by setting the pref gfx.webrender.force-disabled=true and restarting Firefox, make any difference?

Comment 6

[steve]

Elastic overscroll has never worked for me in Firefox 89 or nightly on any website. So it appears to be completely independent of the website visited.
Seeing gfx.webrender.force-disabled=true true in about:config and no overscrolling is happening.

Comment 7

[Botond Ballo [:botond]]

Very strange.

Would you be willing to run a build of Firefox with some extra logging added to try to diagnose the issue further?

Comment 8

[steve]

Certainly. I am highly interested in helping to make this feature work reliably or finding out what local oddity may prevent this from working as expected.

Comment 9

[Botond Ballo [:botond]]

While working on a logging patch I came up with a theory that could explain the observations: do you have a "reduced motion" system setting enabled? Have a look at this page for the various ways to specify that (on Mac, there is a setting in System Preferences, and there's also a Firefox pref, ui.prefersReducedMotion).

This setting disables the overscroll effect (which is an example of avoidable motion), see bug 1705927.

Comment 10

[steve]

Botond - you are spot on! I forgot about this. It is in System Preferences > Accessability > Display > Reduce Motion. Unticking that option makes elastic overscroll work in Firefox without a restart.

This is highly interesting as the reduce motion setting has no effect on Chromium Browsers or Safari. In both cases overscrolling works independently of whether Reduce Motion is active or inactive. Thus I think it is highly debatable whether that setting should affect overscrolling or not. I know the user who filed the feature request from other software projects. They seem to have some form of hyper sensitivity. I am not trying to dismiss their case, but I am wondering if there is another way to tackle this. A brief search did not bring up any solutions to disable overscrolling for Safari or Chrome.

Can I ask what brought you to the conclusion to couple disabling overscrolling to "Reduce Motion"? Did you look into the behavior of other browsers?

Oh I see this question was already raised https://bugzilla.mozilla.org/show_bug.cgi?id=1705927#c18

I am fairly certain this is not an oversight by Apple and Google in their browsers. This clearly is my assumption and not a fact. I just find it odd to change the behavior. My case would be the opposing example to the user who filed the feature request: have reduced motion (to get rid of all the stupid Apple animations which eat time and CPU while trying to get actual work done) and still wanting overscrolling. So here I make my case that this should rather be a config setting allowing edge cases to be covered while keeping overscrolling the default macOS are expecting - even with Reduce Motion enabled.

If you disagree feel free to close this report here. But I think this should at least be briefly discussed with UX.

Comment 11

[Markus Stange [:mstange]]

I agree with steve that it makes sense to follow the platform convention here. Especially since users who really dislike overscrolling can still disable it with the overscrolling pref.

Comment 12

[Botond Ballo [:botond]]

(In reply to steve from comment #10)

Can I ask what brought you to the conclusion to couple disabling overscrolling to "Reduce Motion"?

Mostly based on first principles. The purpose of the prefers-reduced-motion setting is to minimize "non-essential motion". I think it's hard to argue that the overscroll effect is essential: it's purely a visual decoration, its absence does not impair any site functionality, and we've been shipping without it for years prior to its implementation.

I am fairly certain this is not an oversight by Apple and Google in their browsers.

I think it's easy to overlook an accessibility consideration like this. For example, I was not aware of prefers-reduced-motion prior to bug 1705927, not having worked on any other browser feature that is relevant to it.

(In reply to Markus Stange [:mstange] from comment #11)

I agree with steve that it makes sense to follow the platform convention here.

I appreciate that consistency with other browsers / other applications on a given platform is an important consideration, and often the guiding factor for our behaviour.

I also think there's a role for Firefox to sometimes differentiate itself from other browsers in positive ways. We seek to be leaders in privacy, with features like Enhanced Tracking Protection. I think we could seek to be leaders in accessibility too, and that could include taking a conscientious approach to respecting a user's preference for minimizing unnecessary motion.

---

In summary, I suggest we keep this topic open for discussion for now. My preference would be to wait for hear from other browser vendors (specifically, 1. a confirmation that their behaviour is not an oversight, and 2. if so, a rationale for why they don't consider overscroll to be "non-essental motion") before making a change here.

Comment 13

[Botond Ballo [:botond]]

(In reply to steve from comment #10)

My case would be the opposing example to the user who filed the feature request: have reduced motion (to get rid of all the stupid Apple animations which eat time and CPU while trying to get actual work done) and still wanting overscrolling.

I'm sympathetic to this use case. Perhaps there's a way to address it independently on whether prefers-reduced-motion affects overscroll by default.

A couple of suggestions:

1. If your motivation for the "reduced motion" system setting is mostly the OS / other applications than Firefox, you could set the Firefox pref ui.prefersReducedMotion=false, which would override the OS setting for Firefox only.
2. If you'd like the "reduced motion" setting to take effect even within Firefox (e.g. for CSS transitions) just not for the overscroll effect, perhaps we could add a pref like apz.overscroll.force-enabled that overrides the setting for the overscroll feature only.

Comment 14

[steve]

Tried ui.prefersReducedMotion=false true and false but overscrolling would not work in Firefox 89 after a restart of the app.

Thanks for leaving this open to discussion. How do you think feedback from other browser vendors could be gathered? I have little hope Apple will chime in on the discussion in this bug here.

Comment 15

[Botond Ballo [:botond]]

(In reply to steve from comment #14)

How do you think feedback from other browser vendors could be gathered?

My suggestions:

1. Search the Chromium and WebKit issue trackers to see if this issue has come up. (You could help with this part.) If so, we can comment there.
2. If not, we can file a spec issue (against the CSS media-queries spec, which covers prefers-reduced-motion) to start a cross-browser vendor discussion there.

(needinfoing myself to circle back to this next week, including looking into your override issue)

Comment 16

[Botond Ballo [:botond]]

(In reply to steve from comment #14)

Tried ui.prefersReducedMotion=false true and false but overscrolling would not work in Firefox 89 after a restart of the app.

I checked on this. There are a few subtleties:

• The pref needs to be created in about:config, rather than it being already there and you just toggling the value
• The pref needs to be integer-valued, not boolean-valued
• The pref name is case-sensitive

After creating a pref with the correct type and name and value 0, it should take effect and enable overscroll right away without a restart.

Please let me know if you've tried this and it's still not working.

Comment 17

[steve]

Recreated pref with Number instead of Boolean and set value to 0. Not sure about integer-valued - as I am not seeing an option for that. Tried 0 and 1 and overscrolling is still not happening.

Comment 18

[steve]

Attachment: pref.png

Comment 19

[Botond Ballo [:botond]]

My apologies, I was unclear before -- the pref name is just ui.prefersReducedMotion. (The false was the value for it that I suggested trying, before realizing that it actually needs to be a number value 0 rather than false.)

Comment 20

[steve]

This should have been obvious. Actually I should apologize for missing this - temperature is too hot here currently and my brain is operating unreliably :P

ui.prefersReducedMotion with Number 0 and elastic scrolling is working 🎉

Comment 21

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #15)

1. Search the Chromium and WebKit issue trackers to see if this issue has come up. (You could help with this part.) If so, we can comment there.
2. If not, we can file a spec issue (against the CSS media-queries spec, which covers prefers-reduced-motion) to start a cross-browser vendor discussion there.

I could not find related Chromium or WebKit issues, so I went ahead and filed a spec issue about this.

Comment 22

[Hiroyuki Ikezoe (:hiro)]

Just wondering it would be reasonable/acceptable if we respect general.smoothScroll value rather than the system setting? I mean, with general.smoothScroll=false overscrolling still happens but the rubber band effect animation doesn't happen, it immediately scrolls back the the edge when the user's fingers lifted. CCing MarjaE.

Comment 23

[MarjaE]

That sounds reasonable. Although the smoothscroll setting starts off enabled, and about:preferences is hard to navigate.

Comment 24

[Hiroyuki Ikezoe (:hiro)]

Botond suggested to me in a meeting, which is if general.smoothScroll is false, then any overscroll should not happen. I am going to go with the way.

Comment 25

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1714143 - Revert bug 1705927. r?tnikkel

Comment 26

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1714143 - Drop ScrollMetadata::mPrefersReducedMotion. r?tnikkel

Depends on D157689

Comment 27

[Timothy Nikkel (:tnikkel)]

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

Botond suggested to me in a meeting, which is if general.smoothScroll is false, then any overscroll should not happen. I am going to go with the way.

Hmm, I think I sort of see the reasoning behind this? But I might be missing the full case.

On mac with smooth scroll disabled, scrolling using the touchpad is still pixel exact, so it still feels just as smooth. To me this is the motion that is most closely associated with overscroll. So having the smooth scroll pref control overscroll feels a bit weird to me. But I'm very open to hearing more information, other thoughts etc.

Comment 28

[Markus Stange [:mstange]]

I agree with Timothy, having smooth scrolling disabled on macOS and still desiring overscroll seems like it would be reasonably common.

Comment 29

[Hiroyuki Ikezoe (:hiro)]

Okay, so you guys rather prefer the behavior I proposed in comment 22?

Comment 30

[Markus Stange [:mstange]]

Allowing overscroll but snapping back instantly also seems weird. Personally I think we should always have rubberbanding when overscroll is enabled, and whether overscroll itself is enabled shouldn't depend on any other settings. If the motion of the rubberband animation is troublesome for certain users, I think these users can turn off overscrolling completely on about:config.

Comment 31

[Hiroyuki Ikezoe (:hiro)]

Thanks, that sounds totally fair. Okay I am going to use this bug to revert bug 1705927, which means make overscroll not depending on the prefers-reduced-motion system setting. I will defer the problem whether we need to have an option to enable/disable overscroll in about:prefereces or not since about:config is a bit harder to be accessible. (I guess we might end up having "Accesibility" section in about:preferences in these days?).

Comment 32

[Hiroyuki Ikezoe (:hiro)]

Filed bug 1791680 for the preference issue.

Comment 33

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/004ed898613f
Revert bug 1705927. r=tnikkel

Comment 34

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/004ed898613f