1856655 - Scroll position unexpectedly resets

Status: NEW

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

Description

[sorvell]

Steps to reproduce:

In the following reproduction:

1. scroll the orange container to the bottom.
2. click the Click my to update DOM button.

https://jsfiddle.net/hrbc26a4/8/

Actual results:

The scroll position in the orange container resets to the top.

Expected results:

The scroll position in the orange container should not change.

Comment 1

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

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

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Attachment: Standalone test-case.

So, fwiw, this is because my-main is an inline element. If you give it display: block then you shouldn't see the issue.

This is just because with inline/block-splits, we sometimes reconstruct the whole containing block on some DOM changes, and in this case the scroll position is lost.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

I guess the other potential issue is that the scroller is in shadow DOM and this code is probably not accounting for that correctly.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Ok, so we don't restore the scroll position because we use a different state key when removing and when reconstructing, because the removal is what triggers the reconstruct, and the extra children cause our index (and thus state key) to be different.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

So there are three issues:

• The fact that <my-main> is an inline and has blocks causing us to reconstruct the whole containing block.
• The fact that our state restoration code doesn't deal well with shadow DOM, or dynamic DOM mutations.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

I filed dependent bugs for all those things. The more trivial workaround tho is to just make my-main display: block. That prevents hitting the slow path that causes those other bugs to kick in :)

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Curious if you found this in a real page, and if so whether the workaround helps or not. That'd help with prioritization.

Thanks for the excellent reduced test-case too, that helps diagnose immensely :)

Comment 8

[jgreffe]

This issue occurred with a real world page using web components.
This has been simplified to check wether the issue came from the framework or from the browser.

Another workaround is to wrap the header in a <section> or any other block element; as using block style on the my-main element may cause trouble with the other CSS.

Thanks for your answer.

Comment 9

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

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.