Closed Bug 1425739 Opened 6 years ago Closed 6 years ago

Scrolling in Android has a distinct hitch when releasing finger

Categories

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

Product:
Core
Component:
Panning and Zooming
Version:
59 Branch
Platform:
All
Android
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1457586
Tracking Flags:
Tracking Status
geckoview62 --- wontfix
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- affected
firefox63 --- wontfix
firefox64 --- verified

People

(Reporter: joshuakraemer4, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted][geckoview:klar:p2]) 

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171206182557

Steps to reproduce:

Note: The following happens on all current builds of Firefox, from Stable to Nightly
* Go to any webpage long enough to scroll on.
* Scroll vertically through the page using light swipes, enough to cause a "fling", as if you intended to read the page's contents.


Actual results:

When releasing your finger from the swipe, Firefox stops, then suddenly gains speed, for a brief fraction of a second, causing scrolling to feel jerky and off-putting.


Expected results:

Scrolling should be smooth and consistent, like it is in other mobile apps.
OS: Unspecified → Android
Component: General → Panning and Zooming
Product: Firefox for Android → Core
Hardware: Unspecified → All
Version: Firefox 59 → 59 Branch
rbarker, have you noticed this? I haven't really observed this using Fennec in my normal usage. It might be an artifact of flywheel scrolling though.
Flags: needinfo?(rbarker)
See Also: → 1309021
Small update: I've given the android version of Firefox Focus a try. It does not have this problem, scrolling feels much better on Focus, overall.
Not surprising, since Focus doesn't use Gecko at all but uses the system webview implementation.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> rbarker, have you noticed this? I haven't really observed this using Fennec
> in my normal usage. It might be an artifact of flywheel scrolling though.

This sounds like it might be a dupe of Bug 1401526?
Flags: needinfo?(rbarker)
(In reply to Randall Barker [:rbarker] from comment #4)
> (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> > rbarker, have you noticed this? I haven't really observed this using Fennec
> > in my normal usage. It might be an artifact of flywheel scrolling though.
> 
> This sounds like it might be a dupe of Bug 1401526?

No, this happens regardless of whether the URL bar is on screen or not, and regardless of whether the swipe moves it on or off the screen, or leaves it in whatever state it's already in.
This is going to be hard to chase down since we aren't able to reproduce it. It might help to attach a video of the problem so we have a better idea of what it looks like. Then again, videos often don't properly demonstrate scrolling jank so it might not be worth the effort. I think to move forward on this we'd likely have to make a custom build with extra logging, have you run it and reproduce the problem, extract the log and send it back to us.
Priority: -- → P3
Whiteboard: [gfx-noted]
I was able to record my screen; You can see the hitching.
https://www.youtube.com/watch?v=TMue7yTqyFo
Another video is uploading, with the touch inputs being visible...
I am tagging some Fennec bugs related to Chrome scrolling parity.
status-firefox59: --- → wontfix
status-firefox60: --- → wontfix
status-firefox61: --- → affected
Keywords: parity-chrome
Whiteboard: [gfx-noted] → [gfx-noted][geckoview:klar]
Depends on: 1448439
[geckoview:klar:p3] because this bug is not a Klar+GeckoView blocker. We might want to revisit this bug for Fenix. I wonder if this scrolling behavior will improve with Botond's fix for bug 1448439 ("Copy Chrome's fling physics").
status-firefox-esr52: --- → wontfix
status-firefox-esr60: --- → wontfix
Whiteboard: [gfx-noted][geckoview:klar] → [gfx-noted][geckoview:klar:p3]
glamon (UX) says he is able to recreate and would prioritize this as a bug that is noticeable and feels "wrong".
Blocks: android-scrolling
status-firefox61: affected → wontfix
status-firefox62: --- → affected
status-firefox63: --- → affected
No longer depends on: 1448439
Keywords: parity-chrome
Whiteboard: [gfx-noted][geckoview:klar:p3] → [gfx-noted][geckoview:klar:p2]
Markus had a theory that bug 1457586 might fix this too.

Joshua, are you able to test the behaviour on Firefox Nightly to see if this bug still occurs?
Flags: needinfo?(joshuakraemer4)
Re-downloading Firefox Nightly onto my phone, it does appear that the transition from scrolling to flinging is noticeably smoother.
Flags: needinfo?(joshuakraemer4)
Fantastic! Thanks for confirming; I'm going to close this as a dupe of bug 1457586.
dupe of bug 1457586 as per comment 14
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
status-firefox63: affected → wontfix
status-firefox64: --- → verified
status-geckoview62: --- → wontfix
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.