1812227 - Android webpages jump "up" every so often while scrolling down

Status: RESOLVED FIXED

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

Description

[Jonathan Almeida [:jonalmeida]]

From github: https://github.com/mozilla-mobile/fenix/issues/25688.

Steps to reproduce

1. Open https://aphyr.com/posts/358-a-history-of-leather-at-pride-1965-1995
2. Wait for the page to finish loading
3. Slowly scroll down (as if reading the page)

Expected behaviour

Page scrolls smoothly.

Actual behaviour

The page jumps up and is not smooth.

Device name

Google Pixel 6 Pro (also witnessed on Moto G30)

Android version

Android 12

Firefox release type

Firefox

Firefox version

Release 101.2 (also witnessed on Nightly 103)

Device logs

No response

Additional information

SUMO Forum question: https://support.mozilla.org/en-US/questions/1380100

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

[Jonathan Almeida [:jonalmeida]]

I've been able to reproduce this myself with Instagram as well. Reported as a webcompat bug originally: https://github.com/webcompat/web-bugs/issues/115794#issuecomment-1362014526

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Kim Lindberger [:talyz]]

This happens to me all the time as well. Android 13 on a OnePlus 9 Pro. It's particularly noticable when viewing code on GitHub, for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/shells/fish/default.nix

Comment 4

[Mihai Morariu]

I confirm that I'm experiencing the same issue, especially when accessing Instagram and Facebook.

Just wondering, do you have the uOrigin add-on installed? I disabled it and haven't had any issues in a few days. Cannot say for sure whether it's just luck or the issue is actually related to the add-on. Will keep it disabled for a few more weeks and then report again - it might be a starting point for fixing this annoying bug.

Device: Sharp Aquos sense4 Plus
Android version: 11
Firefox version: 113.1.0 (Build #2015950739)

Comment 5

[Mihai Morariu]

Sorry, I meant uBlock Origin (not uOrigin).

Comment 6

[daboross]

I did have it enabled. I've disabled it, and the issue persists. Interestingly, the issue is no longer present on the original URL without uBlock Origin enabled, but it does persist on other pages (latest after disabling, an account-only page on eTrade, a stock platform - https://us.etrade.com/etx/sp/stockplan/#/myAccount/orders?vanity=planvieworders)

Perhaps uBlock Origin is changing the DOM in some way to cause this, but pages can also just have the DOM that way to start with, or change it themselves from JS?

Comment 7

[Mihai Morariu]

Does it still happen if you wait for 1-2 seconds after loading the page?

I've just checked and I am experiencing the same issue. I clicked on the link you posted, immediately started to scroll, then the page "jumped". What I noticed is that it takes a second or two before the page finishes loading and the focus is set on the first text box (User ID). If I wait a bit until the page is fully loaded, the I am no longer seeing that behavior.

Comment 8

[daboross]

I no longer seem to be able to reproduce the issue with https://aphyr.com/posts/358-a-history-of-leather-at-pride-1965-1995 at all. It doesn't seem to have been copied to this ticket, but here's a screen recording I took after I reported the issue, when the aphyr.com article was reliably causing it: https://youtu.be/Y01uwaMSQ1o

I do not believe it's what you're describing. Rather, I waited until it fully loaded, and then every time I scrolled a certain amount, it would jump up. It's hard to describe, though, so I hope the video helps.

When it happens, the page continues to jump up every time I scroll down.

Now, I can't reproduce it on that article at all - uBlock Origin seems to make no difference installed or not. However, I still notice it on other pages, always scrolling well after the initial page load. It's very inconsistent, but when it occurs, it keeps happening on the page it occurred on at least until I restart Firefox for Android.

Comment 9

[daboross]

Apologies, I realized I didn't answer your question directly. Yes, it happens if I wait 1-2 seconds. On the aphyr.com article, when it was happening there, it usually took 10-30 seconds of scrolling before it happened, and in that video in particular, I did wait 3 seconds before starting to scroll.

Comment 10

[Mihai Morariu]

Thanks for your reply!

Do you have an Instagram account? If yes, could you try to scroll the home page with and without uBlock Origin installed?

For me the behavior is pretty consistent and I'm thinking it could be a starting point for finding the cause of this bug. But I'm not ruling out the possibility that it might just be luck.

Comment 11

[Linus Kardell]

Attachment: Record_2023-06-30-23-44-11.mp4

On Instagram and Facebook it does seem to be related to uBo in my experience. But there are other sites where it happens with uBo disabled, for example on https://biosector01.com/wiki/Main_Page as shown in the attached video.

I also get similar issues on https://fof.se/, but that site does the same in Chrome, unlike the aforementioned.

Comment 12

[Linus Kardell]

I noticed this issue on Wikipedia as well now, when scrolling through the table at https://en.m.wikipedia.org/wiki/SUSE_Linux#SUSE_distributions

Comment 13

[Hao Tian]

This happens for me on https://github.com/hooke007/MPV_lazy/wiki/0_FAQ . I can ~100% trigger the issue with these steps:

1. Open the link above
2. Wait till the page fully loads
3. Go back to launcher (by swiping up from the bottom of screen)
4. Go back to Firefox (by tapping its icon in the launcher)
5. Swipe up on the page

There are two devices that exhibit the issue:

Device: Xiaomi 14
Android version: Android 14 (HyperOS 1.0.24.1.16.DEV)
Firefox release type: Firefox from Play Store (also happens on Firefox beta)
Firefox version: 121.1.0 (122.0b9 for Firefox beta)
Device logs: (what logs are needed, adb bugreport or something else?)

Device: RedMagic 8S Pro
Android version: Android 13 (RedMagic OS 8.0.22MR2)
Firefox release type: Firefox (manually installed by APK)
Firefox version: 116.3.0

However I could not reproduce the issue on the exact same RedMagic 8S Pro with a PixelExperience 13 (Android 13) system installed by DSU.

What should I do next? I'm open to any suggestions from taking logs to recompiling Firefox.

Comment 14

[[:owlish] 🦉 PST]

Hey folks can you please take a look?

Comment 15

[eclaudiu64]

There are 2 open tickets also on GitHub webcompat, seems related:

1. https://github.com/webcompat/web-bugs/issues/136375
2. https://github.com/webcompat/web-bugs/issues/136396

Comment 16

[eclaudiu64]

(In reply to eclaudiu64 from comment #15)

There are 2 open tickets also on GitHub webcompat, seems related:

1. https://github.com/webcompat/web-bugs/issues/136375
2. https://github.com/webcompat/web-bugs/issues/136396

I think these tickets on Github are related to this bug. I think this error deserves some attention because it affects most sites.

Comment 17

[eclaudiu64]

Attachment: mobizen_20240522_170032_001_002.mp4

Another site that reproduces the error: https://8ballpool.com/en/shop
With small scrolls or fast scrolls, the page jumps. It must be investigated, because it also affects YouTube (link attached here from Webcompat).

Comment 18

[Botond Ballo [:botond]]

Thanks for getting this bug on our radar.

The symptom here is a fairly generic one that could potentially have a variety of causes including issues with site-specific JS as well as potentially platform issues.

I think some good next steps are:

• Go through the various websites mentioned in the comments on this bug, and in linked issues
• For sites where the issue is reproducible, file individual bugs with their own STR blocking this bug
• Turn this bug itself into a meta bug

I've reached out to our QA team for help with this task.

Comment 19

[eclaudiu64]

You would need a lot more involvement in this error because it affects a user's navigation.

Comment 20

[eclaudiu64]

Can we consider paying more attention to this error? I see this error on about 60% of the sites I access.

Comment 21

[Botond Ballo [:botond]]

(In reply to eclaudiu64 from comment #20)

Can we consider paying more attention to this error? I see this error on about 60% of the sites I access.

Could you file a new bug for the issue you're seeing please? As I mentioned, I suspect there may be several different issues here, e.g. an issue that you're experiencing on 60% of sites is likely to be different from the originally reported issue about a jump of 1-2 paragraphs on a specific site, and it gets confusing to talk about it all in one issue thread. We can always dupe one bug over to another if they turn out to have the same cause.

Comment 22

[3rwswdevo]

This is really big issue and i just made an account to report this has been an issue for me for more than a year on facebook and some other pages, it jumps so much and so often its hard to navigate pages, please look into it

Comment 23

[Botond Ballo [:botond]]

(In reply to 3rwswdevo from comment #22)

This is really big issue and i just made an account to report this has been an issue for me for more than a year on facebook and some other pages, it jumps so much and so often its hard to navigate pages, please look into it

For Facebook in particular, they have some sort of virtual scrolling mechanism that removes posts that have been scrolled offscreen at the top and adjusts the scroll position to try to keep the current post in view, which is likely responsible for the observed jumps.

We've put a lot of effort into trying to debug this and have rolled out five different attempted fixes in Firefox versions ranging from 115 to 125, as discussed in bug 1858022 comment 38. It seems like the fixes have improved the behaviour but I guess have not completely fixed the jumps.

As I've suggested in that linked comment, please also reach out to Facebook Support about this, because they are in a better position to help investigate this than we do (i.e. they have access to the non-obfuscated version of the Javascript code that runs on their website).

Comment 24

[Vasilica Tamas QA [:vtamas]]

Attachment: Recorder_14062024_165031.mp4

I was able to reproduce this issue constantly on https://en.m.wikipedia.org/wiki/SUSE_Linux#SUSE_distributions on Firefox Nightly 129 (2024-06-14), Firefox 128 Beta 2, and Firefox 127.0 under Google Pixel 8 (Android 14), Xiaomi 12T (Android 12) and OnePlus 6T (Android 11).

Investigated a bit more and this seems to be an old regression: Last Good build [2022-10-09] - First Bad build [2022-10-10]

I also tried to reproduce this issue on the other pages mentioned in this bug as being affected and on the top 20 most popular sites as well but without success.

Comment 25

[Timothy Nikkel (:tnikkel)]

(In reply to Vasilica Tamas from comment #24)

Investigated a bit more and this seems to be an old regression: Last Good build [2022-10-09] - First Bad build [2022-10-10]

Can you get the changeset ids for those builds so we can see what changes happened then?

Comment 26

[Vasilica Tamas QA [:vtamas]]

(In reply to Timothy Nikkel (:tnikkel) from comment #25)

Can you get the changeset ids for those builds so we can see what changes happened then?

Here are the builds details:

• Last Good build [2022-10-09]: 107.0a1 (Build #2015908875), 6c89feb0c+ , AC: 107.0.20221009143152, f98e3df228, GV: 107.0a1-20221009094451, AS: 94.2.1
• First Bad build [2022-10-10]: 107.0a1 (Build #2015909067), 8da9ba432+ , AC: 107.0.20221010143126, bc36830dd9, GV: 107.0a1-20221010033207, AS: 94.2.1

Comment 27

[Timothy Nikkel (:tnikkel)]

Thanks!

Hmm, none of the hashes seems to be revisions on mozilla central, must be from some fenix repository. I wonder who might know how to go from that to a list of changesets.

Comment 28

[Chris Peterson [:cpeterson]]

(In reply to Vasilica Tamas from comment #26)

Here are the builds details:

• Last Good build [2022-10-09]: 107.0a1 (Build #2015908875), 6c89feb0c+ , AC: 107.0.20221009143152, f98e3df228, GV: 107.0a1-20221009094451, AS: 94.2.1
• First Bad build [2022-10-10]: 107.0a1 (Build #2015909067), 8da9ba432+ , AC: 107.0.20221010143126, bc36830dd9, GV: 107.0a1-20221010033207, AS: 94.2.1

(In reply to Timothy Nikkel (:tnikkel) from comment #27)

Hmm, none of the hashes seems to be revisions on mozilla central, must be from some fenix repository. I wonder who might know how to go from that to a list of changesets.

@ Ryan, what is the recommended process for identifying or bisecting a (2022) regression range from the old fenix repo on GitHub?

Comment 29

[Botond Ballo [:botond]]

(In reply to Chris Peterson [:cpeterson] from comment #28)

(In reply to Vasilica Tamas from comment #26)

Here are the builds details:

• Last Good build [2022-10-09]: 107.0a1 (Build #2015908875), 6c89feb0c+ , AC: 107.0.20221009143152, f98e3df228, GV: 107.0a1-20221009094451, AS: 94.2.1
• First Bad build [2022-10-10]: 107.0a1 (Build #2015909067), 8da9ba432+ , AC: 107.0.20221010143126, bc36830dd9, GV: 107.0a1-20221010033207, AS: 94.2.1

(In reply to Timothy Nikkel (:tnikkel) from comment #27)

Hmm, none of the hashes seems to be revisions on mozilla central, must be from some fenix repository. I wonder who might know how to go from that to a list of changesets.

I believe the information in those build descriptions relevant for getting a mozilla-central regression range is "GV: 107.0a1-20221009094451" and "GV: 107.0a1-20221010033207". I believe the numbers starting with 2022 are build IDs of the mozilla-central builds which contributed the GeckoView artifact, which we can ask mozregression to translate to a pushlog:

$ mozregression --good 20221009094451 --bad 20221010033207
 0:01.08 INFO: Got as far as we can go bisecting nightlies...
 0:01.08 INFO: Last good revision: b8567457ece9593ddb00344130597698145bdc5c (2022-10-09 09:44:51)
 0:01.08 INFO: First bad revision: d420f9190e2f35e314aa67ee346650f86451792c (2022-10-10 03:32:07)
 0:01.08 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b8567457ece9593ddb00344130597698145bdc5c&tochange=d420f9190e2f35e314aa67ee346650f86451792c

Here is that pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b8567457ece9593ddb00344130597698145bdc5c&tochange=d420f9190e2f35e314aa67ee346650f86451792c. Bug 1755044 in there is related to touch scrolling, that's a potential culprit.

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 31

[Donal Meehan [:dmeehan]]

:botond could this be triaged for severity?

Comment 32

[Markus Stange [:mstange]]

I encounter this most often when the touch down position is on a horizontally-scrollable subframe on a vertically-scrollable page.

Comment 33

[Botond Ballo [:botond]]

(In reply to Vasilica Tamas from comment #24)

I was able to reproduce this issue constantly on https://en.m.wikipedia.org/wiki/SUSE_Linux#SUSE_distributions on Firefox Nightly 129 (2024-06-14), Firefox 128 Beta 2, and Firefox 127.0 under Google Pixel 8 (Android 14), Xiaomi 12T (Android 12) and OnePlus 6T (Android 11).

Investigated a bit more and this seems to be an old regression: Last Good build [2022-10-09] - First Bad build [2022-10-10]

I also tried to reproduce this issue on the other pages mentioned in this bug as being affected and on the top 20 most popular sites as well but without success.

Thank you for the test case and regression range!

I was able to reproduce this and verify the regression range. Some notes to help reproduce the issue:

• Scroll with small flicks, where the finger is in contact with the screen for a brief period of time, but the flick also isn't too strong, so you get momentum scrolling for a short distance
• Start the next flick soon after the previous one, so that the momentum scrolling hasn't yet completely stopped

The jumps that I see are relatively small, but noticeable if you pay attention.

In terms of severity, the bug does not prevent you from reaching a desired scroll destination, but it is slightly annoying (e.g. you may have to perform a few more flicks to get to where you want; your reading flow may be disrupted by the jumps). I'm going to mark it as S3 and P2, and raise it with the team for prioritizing along with the other "wonky scrolling on Android" APZ bugs tracked in bug 1895538.

Comment 34

[Botond Ballo [:botond]]

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

Bug 1755044 in there is related to touch scrolling, that's a potential culprit.

I've checked that a local backout of bug 1755044 fixes this, thus confirming it as the regressing bug.

Comment 35

[Botond Ballo [:botond]]

I will investigate the regression discussed in comment 29 / comment 33.

Comment 36

[Botond Ballo [:botond]]

Investigation so far is pointing to MaybeSplitTouchMoveEvent() (a function added in bug 1755044) synthesizing an interpolated touch-move event with an incorrect touch point (i.e. one that's not in between the touch point of the previous event and the touch point of the new event), which makes the stream of processed touch points look as though the finger has been moved briefly in the opposite direction and then back.

Comment 37

[Botond Ballo [:botond]]

I believe I tracked down the cause of the bug. It's fairly subtle.

The touch event objects processed by APZ store two copies of their coordinates in two different data members: mScreenPoint stores the global coordinates of the touch relative to the screen, and mLocalScreenPoint stores the coordinates relative to the APZC which is processing the event (more specifically, relative to its composition bounds). The first one is set by widget code when creating the event; the second one is computed when an event is dispatched to an APZC by applying a transform to the first one representing the position of the APZC's composition bounds relative to the screen.

The interpolation in MaybeSplitTouchMoveEvent() operates on screen coordinates (because the touch-move threshold is specified in screen inches), and sets the mScreenPoint of the synthesized event. It's then necessary to compute and set the mLocalScreenPoint of the synthesized event.

The code does this. However, there's an unfortunate snag: if the target APZC is a subframe and the scroll is being handed off to an ancestor, then the composition bounds of the target APZC itself are changing over the course of the gesture. As a result, the transform from global coordinates to local coordinates is itself changing.

To handle this, we cache the transform at the beginning of the input block, and use the cached transform for all events in the input block, so that their local coordinates are all in the same coordinate system and comparable to each other.

The bug is that MaybeSplitTouchMoveEvent() is not using the cached transform from the input block: it's recomputing an up-to-date transform at that moment, and calculating mLocalScreenPoint based on that. As a result, the coordinates of the synthesized event are actually in a different coordinate system than the real event before it, and trying to interpret them as being in the same coordinate system results in the observed bad behaviour.

The fix is simple: have the input block expose the cached transform and use it to compute the local coordinates of the synthesized event.

Comment 38

[Botond Ballo [:botond]]

Attachment: Bug 1812227 - Use InputBlockState::mTransformToApzc to compute the local coordinates of the synthesized touch event in MaybeSplitTouchMoveEvent(). r=dlrobertson

For events in a given input block to have coherent local coordinates
(so that e.g. it's sensible to compute a delta between the local
coordinates of two adjacent events), it's important that the local
coordinates are computed using the same screen-to-apzc transform
for all events.

To facilitate this, the transform is cached at the beginning of the
input block in InputBlockState::mTransformToApzc, and all events
in the block are expected to use it.

MaybeSplitTouchMoveEvent() was synthesizing and processing a new event
without using this cached value, resulting in misbehaviour.

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/091c8629442f
Use InputBlockState::mTransformToApzc to compute the local coordinates of the synthesized touch event in MaybeSplitTouchMoveEvent(). r=dlrobertson

Comment 40

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/091c8629442f