1692705 - Setting scrollTop discards async scroll offsets and can cause the page to jump unexpectedly

Status: RESOLVED DUPLICATE of bug 1692708

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

Description

[Markus Stange [:mstange]]

Attachment: testcase

Some websites, like Slack, lazily load content at the top of a scroll frame. When they insert that content, the existing content shifts down. To avoid a visual shift, they adjust the scroll position by adjusting the scrollTop property.

However, in Firefox, assigning to scrollTop resets any async scroll offset. This means that, if the content is inserted while the user is scrolling, there will be a perceptible jump.
Because of this jump (and because of bug 1692708), Slack is currently giving Firefox a slower path where they load more content upfront and only do the adjustment when they know that the user is not scrolling.

We have a relative-scroll-update mechanism that we use for the scrollBy method but not for scrollTop. I think it would be a good idea to use it for scrollTop as well, and probably also for the scrollTo() method.

The guiding principle should be: If a scenario didn't discard scroll offsets when using main thread scrolling, then we shouldn't discard scroll offsets with async scrolling either.

Steps to reproduce:

1. Load the attached testcase.
2. Switch to the setting document.scrollingElement.scrollTop option with the radio button.
3. Scroll up and down the page, with a mechanism that does not use APZ animations. For example, use the touchpad on macOS, or use wheel scrolling with smooth scrolling disabled, or use touch scrolling on a touch screen but without flinging.

Expected results:
No jumps, no sudden pauses. The page should feel stable.

Actual results:
Frequent jumps and generally glitchy scroll feeling.

In Chrome, the page feels stable in all modes.
In Safari, the page feels glitchy in all modes. I'm not sure how Slack treats Safari.

Comment 1

[Botond Ballo [:botond]]

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

Steps to reproduce:

1. Load the attached testcase.
2. Switch to the setting document.scrollingElement.scrollTop option with the radio button.
3. Scroll up and down the page.

Just to make sure I understand: this is similar to the STR in bug 1692708, but the scrolling is done with a trackpad?

Comment 2

[Markus Stange [:mstange]]

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

Just to make sure I understand: this is similar to the STR in bug 1692708, but the scrolling is done with a trackpad?

Yes, that's the easiest way. I've clarified the original comment a little bit. The other means of scrolling also discard the async scroll offset, but this effect is harder to look at in isolation if there's an APZ animation running at the same time.

Comment 3

[Frank Griffith Jr]

Updated Assignee. Part of Jira Epic FFXP-370

Comment 4

[Hiroyuki Ikezoe (:hiro)]

IIRC this bug and bug 1692708, it seems there's nothing difference we can do for both bugs. In both cases, an obvious problem is that the script, the getter scrollTop call is invoked before a scroll position changed by APZC has been reflected to the main-thread. A solution Botond told me on Matrix, making Element.scrollTop call relative scroll change regardless whether there's APZ animation or not sounds a promising way. (we should ignore scrollTop=0 case though).

Anyway, taking over from Timothy.