1610952 - Fenix jumps up while scrolling

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect)

Description

[__oldboek]

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

Steps to reproduce:

Open https://mobile.twitter.com/jensimmons/status/1186639878169251840
Scroll down slowly

https://github.com/mozilla-mobile/fenix/issues/6176

Actual results:

From time to time it jumps up
https://vimeo.com/367964926

https://github.com/mozilla-mobile/fenix/issues/6176#issuecomment-577019563

Expected results:

Continuous scroll down

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

Botond, can you take a look?

Comment 2

[Emily Toop (:fluffyemily)]

Hi Kris. There are now a large number of scrolling behavior issues filed on Fenix, of which this is one. Is there any chance that we could get this prioritised for Gecko 75?

Comment 3

[Botond Ballo [:botond]]

Does the issue reproduce with layout.css.scroll-anchoring.enabled=false?

If yes, it would be helpful to get a regression window (since the github issue suggests this is a regression).

Comment 4

[Jamie Nicol [:jnicol]]

Looking around the various github issues, it's not entirely clear whether webrender is enabled or not. Nor can I reproduce myself on some of the URLs (ie twitter). I can however very easily reproduce with webrender enabled on bugzilla.mozilla.org. And I believe I understand what the cause is.

So I'll put a patch up on this bug for that fix, then we can assess whether the other websites are the same root cause, and file more bugs if necessary?

Comment 5

[Jamie Nicol [:jnicol]]

Attachment: Bug 1610952 - Ensure webrender's async scroll offsets are in correct coordinate space. r?botond

For zoomable APZCs, we were correctly dividing the scroll offset by
the pinch zoom scale. This is effectively equal to multiplying by the
device pixel ratio then dividing by the zoom, converting the offset
from parent layer space to layout device space.

However, for non-zoomable APZCs, we were incorrectly assuming that the
pinch zoom scale equalled 1.0. This was causing us to send incorrectly
scaled async scroll offsets to webrender, resulting in content moving
too slowly or quickly whilst asynchronously panning, then suddenly
jumping as the synchronous scroll offset caught up.

This is fixed by ensuring we always divide the asynchronous scroll
offset by the pinch zoom scale, regardless of whether the APZC is
zoomable or not.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/81f38cb81ac6
Ensure webrender's async scroll offsets are in correct coordinate space. r=botond

Comment 7

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/81f38cb81ac6

Comment 8

[Wes Kocher]

Using today's Preview Nightly build (Nightly 200212 06:01, GV: 74.0a1-20200210093912), it behaves slightly differently than it did before.

If you load https://mobile.twitter.com/tesseralis/status/1227672340198121472 it should scroll normally. If you scroll down far enough to see and tap one of the "X more replies" links, the page then starts gradually scrolling back up to the top of the page, and further efforts to scroll down the page will end up with the scroll position being back at the top of the page.

I haven't had a chance to test this patch against the bugzilla example, so maybe this should go into a new bug, but thought I'd chime in here first...

(Here's a horribly-formatted copy of my about:support info, if that helps: https://paste.mozilla.org/2Dz43FwP )

Comment 9

[Wes Kocher]

(In reply to Botond Ballo [:botond] [spotty responses until Feb 19] from comment #3)

Does the issue reproduce with layout.css.scroll-anchoring.enabled=false?

If yes, it would be helpful to get a regression window (since the github issue suggests this is a regression).

Yes, I toggled that pref to false in Preview Nightly and still had the same issues on the twitter example.

Comment 10

[Wes Kocher]

And for a regression range, this started happening in Preview Nightly 190927 (gecko 71.0a1-20190926094200).

The 190926 build (gecko 71.0a1-20190923094800) behaves correctly.

Comment 11

[Jamie Nicol [:jnicol]]

I guess the bugzilla and the twitter issues are unrelated, then. I could only reproduce the bugzilla one originally, which is now fixed. I never could reproduce twitter...

What is the difference in behaviour between the latest nightly and say a week ago?

And what is the difference in behaviour between GV 2019-09-26 and 2019-09-23? If you could use mozregression --app gve to narrow down that regression range, that would be incredibly helpful!

I note that regression range predates webrender being enabled on Nightly Pixel 3, so presumably this affects both webrender and non-webrender.

Comment 12

[Wes Kocher]

mozregression --app gve gives me https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e2ddce1acc62b1e1bf367a226b0cb64a8cec7e78&tochange=f94173bcd08dcb7059333c7e01ac8ab5c53de63e as the regression range.

Comment 13

[Wes Kocher]

(In reply to Jamie Nicol [:jnicol] from comment #11)

What is the difference in behaviour between the latest nightly and say a week ago?

And what is the difference in behaviour between GV 2019-09-26 and 2019-09-23?

The original (correct) behavior, prior to the 2019-09-27 build: If you scroll down a thread of tweets on Twitter and then tap one of the "X more replies" links, the additional replies load, and the scroll position stays where it was to begin with. Further scrolling down works as expected.

The behavior starting with the 2019-09-27 build: If you scroll down a thread of tweets on Twitter and then tap one of the "X more replies" links, the additional replies load, but the scroll position snaps back up to nearly the top of the page. Further attempts to scroll downward work somewhat but occasionally teleports you back to the top of the page. (I think it happens when you approach the point in the thread where the additional replies were loaded, but I can't say for sure.)

The behavior in recent Nightlies (with the patch from this bug): Similar to the behavior on the 2019-09-27+ builds, but the teleporting back up to the top of the page sometimes happens in smaller increments, rather than in one big leap.

Comment 14

[Jamie Nicol [:jnicol]]

Thanks! Seems like a separate issue so filed bug 1615562.

Comment 15

[Stefan Deiac]

Verified using the latest version of Firefox Preview Nightly 2/16 #20470606.
Device: Samsung Galaxy S8 (Android 9).
Due to that, I'll close this issue as verified, thanks.

Comment 16

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

Bugbug thinks this bug is a regression, but please revert this change in case of error.