Closed Bug 1380316 Opened 7 years ago Closed 6 years ago

Improve APZ fling scroll physics values on Android


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

56 Branch



Tracking Status
fennec ? ---
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- affected


(Reporter: bullionareboy, Assigned: Carol)



(Keywords: parity-chrome, uiwanted, Whiteboard: [geckoview:klar][gfx-noted])

The current scroll physics causes much stress on the user who tends to reads long articles or have to scroll through very long pages. 

A user posted on reddit with scroll physics values(for - apz.fling_curve_function) that tend to bring the fling scroll experience much closer or better to Chrome and stock android browsers.  

Both posts are linked here:

And i must say after using the fling values(x1=0, x2=0, y1=0.21, y2=0.91) in link 1, my experience with Firefox is miles and miles better.  
They still can be fine tuned further.   

An easy test would be to scroll or the's any long-form article
Its a very long page and in Chrome or Webkit browser you just need 2 flings to reach the bottom of the page. 
With Firefox default values it requires 4-5 flings  

Please modify the default values to reduce the number of flings required. 
This would bring us on par with android scroll experience and eliminate the plaguing scroll experience on Fennec for normal users
Flagging as uiwanted to get UX feedback on the suggested pref values.
Ever confirmed: true
Keywords: uiwanted
Priority: -- → P3
I'm not sure how welcome user feedback under a bug is, but I thought I'd throw in my two cents:

Scrolling physics values currently used in Nightly for Android make the websites feel "heavier" (i.e. "weighing" more). Not only maximum scrolling speed when flinging the page is lower when compared to native Android scrolling, it also seems to me that Firefox is waiting a fraction of second longer when I'm trying to scroll with my finger before it registers the input as swipe. The result is a website that doesn't seem to follow my finger closely when swiping, and it's really frustrating. It's difficult for me to explain it, but whenever I use a Chromium-based browser, it feels like the website is following my finger much closer, to the point where I feel like I'm actually touching the website itself, not the display it's shown on, if it makes any sense, heh.

I tried the values from (x1=0, x2=0, y1=0.21, y2=0.91), and while they "feel" a bit better than the defaults, it seems to me that they make the website accelerate at faster rate than default, which is also slightly annoying. It also makes the scrolling animation more janky. I'm running Firefox Nightly on Sony Xperia XZ Premium, so I doubt it's an issue with insufficient resources.
Completely agreed with the above comments. I've tried the values that were shared above, but the 'feel' and general jankiness of the animation while scrolling makes Firefox really unpleasant to use on my Galaxy S8+.
This is the main reason I can't get used to Firefox on android.  I definitely think Firefox should try to match Chrome's fling physics.  There is also a noticeable lag for me when you just put your finger on the screen and drag the website up and down, in comparison the Chrome.  I'm using a Nexus 5X btw.
tracking-fennec: --- → ?
Scrolling of Firefox browser is terrible in the Android. Unless this is fxed I can't use as my default browser.
It is most Janky browser in Android
I am tagging some Fennec bugs related to Chrome scrolling parity.
Component: Toolbar → Panning and Zooming
Keywords: parity-chrome
Product: Firefox for Android → Core
Hardware: ARM → All
Summary: Improve APZ fling scroll physics values → Improve APZ fling scroll physics values on Android
Whiteboard: [geckoview:klar]
Assigning to Carol since this is going to be UX driven, same as bug 1421644.
Assignee: nobody → chuang
Whiteboard: [geckoview:klar] → [geckoview:klar][gfx-noted]
Depends on: 1448439
I think this bug is a duplicate of bug 1448439 ("Copy Chrome's fling physics"), which Botond is fixing.
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.