1850036 - scroll position jumps after dom update when page was reflowed after re-load before restoring the previous scroll position

Status: NEW

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[Gavin Cannizzaro]

Attachment: bug.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

• load a page that causes any reflow asynchronously
• scroll until the reflowed content is out of view
• reload the page (which preserves its scroll position)
• click a button that causes a DOM update

The attached page contains a complete, self-contained and minimal repro case with additional notes.

Actual results:

The DOM update is made AND the page's scroll position jumps up by about one line (though I was seeing much larger jumps in my actual environment).

Expected results:

The DOM update is made without any change to the page's scroll position.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Gavin Cannizzaro]

Here are the notes included in the repro page:

This is a "DHTML" bug—it involves only web features that existed in the 20th century. So I would expect it to be a regression from more recent features. I suspect that it is related to the scroll-anchoring implementation, like this bug.

• Content must be added dynamically after page load, and above the button (or rather, the place you're scrolled to whenever the second DOM update occurs)
• Content must be added asynchronously after page load. The test here uses a zero-millisecond timeout.
• The jump happens only when the on-load DOM update caused a reflow, i.e. attribute changes and inline text updates do not cause it.
• The jump happens only when the dynamically-changed content is out of view.
• The jump happens only when the on-click makes certain DOM updates. A reflow is not required here, but an attribute change won't do it.
• The jump happens only the first time the button is pushed.

Comment 3

[Botond Ballo [:botond]]

(In reply to Gavin Cannizzaro from comment #2)

So I would expect it to be a regression from more recent features. I suspect that it is related to the scroll-anchoring implementation, like this bug.

Indeed, the bug does not reproduce with layout.css.scroll-anchoring.enabled set to false in about:config, so this is a regression from scroll anchoring.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

I've got a regression range; https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ed36965e2ae45eafc53530beadf293451fa6ad62&tochange=c21abcd26992ed15968d46891435326eed5a78d7

There's nothing super suspicious for me, but bug 1754562 is the most plausible one. That being said, I think the real regressor is bug 1546027. Since bug 1546027 we don't apply scroll anchoring when we haven't finished restoring the scroll position, thus

(In reply to Gavin Cannizzaro from comment #2)

• The jump happens only when the on-load DOM update caused a reflow, i.e. attribute changes and inline text updates do not cause it.

We can't detect this change in scroll anchoring stuff.

Setting P3:S3 since it's not a recent regression.

Comment 5

[Alice0775 White]

Regression window (slightly narrowed):
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d542a202cb0d02116fa231185e75aef76e68341c&tochange=c21abcd26992ed15968d46891435326eed5a78d7

Suspect:Bug 1753881

Comment 6

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

:tnikkel, since you are the author of the regressor, bug 1753881, could you take a look?

For more information, please visit BugBot documentation.

Comment 7

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

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

Comment 8

[Timothy Nikkel (:tnikkel)]

Regression that's been around 18 months, so I'm probably not going to get to this quickly.

Comment 9

[Timothy Nikkel (:tnikkel)]

I'm cancelling my needinfo solely so that bugbot will stop sending me "Bugs with a ni on a bug marked as affecting a released version without activity for the last 1 week" emails since almost all needinfos are about bugs that affect released versions.