1910988 - {inc} Incorrect sticky positioning of CSS grid child item if reflowed from out of scrollport to partially in scrollport

Status: NEW

(Core :: Layout: Grid, defect)

Description

[caleb]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15

Steps to reproduce:

TLDR: visit https://jsfiddle.net/L8k1tfvy/1/. Inspect element on the yellow square and the text appears, even though no JS was run (forced layout).

These are the conditions, as far as I've been able to narrow them down. The main layout is parent > grid > child:

1. Pre-existing content underneath the parent is removed and a new grid placed there, in JS, synchronously
2. The grid has a child item with sticky positioning, and the parent is the scrollport
3. The grid is positioned so that the child item wouldn't appear if it were relatively positioned (e.g. left: -100000px)
4. Asynchronously, the grid is moved into view (e.g. left: 0px;)

This bug has been dogging us since it showed up somewhere around 6+ months ago. Recently it started manifesting a lot more.

Actual results:

The grid's child item doesn't show up unless you inspect element, resize the browser window, or similar.

Expected results:

The grid's child item should show where it would have had the final layout been the starting layout.

Comment 1

[caleb]

(In reply to caleb from comment #0)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15

Steps to reproduce:

I forgot to narrow down step 1: pre-existing content doesn't matter. Again, with the same main layout of parent > grid > child:

1. An element with display: grid is appended to the parent
2. The grid has a child item with sticky positioning, and the parent is the scrollport
3. The grid is positioned so that the child item wouldn't appear if it were relatively positioned (e.g. left: -100000px)
4. Asynchronously, the grid is moved into view (e.g. left: 0px;)

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case from comment 0

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Thanks for the test-case! This smells a lot like the RecomputePosition fast-path for left / right / top / bottom changes not working as intended in this situation, though I'd be curious to know if it's a regression.

Comment 4

[Alice0775 White]

At least, I can reproduce the issue on nightly59.0a1(20171201105203) with webrender enabled on windows11....

Comment 5

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

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

For more information, please visit BugBot documentation.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Alice0775 White from comment #4)

At least, I can reproduce the issue on nightly59.0a1(20171201105203) with webrender enabled on windows11....

Same here (on Ubuntu). Seems like probably not a regression then --> removing regression-related keyword/QA-whiteboard-status.