{inc} Incorrect sticky positioning of CSS grid child item if reflowed from out of scrollport to partially in scrollport
Categories
(Core :: Layout: Grid, defect)
Tracking
()
People
(Reporter: caleb, Unassigned)
Details
Attachments
(1 file)
697 bytes,
text/html
|
Details |
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:
- Pre-existing content underneath the parent is removed and a new grid placed there, in JS, synchronously
- The grid has a child item with sticky positioning, and the parent is the scrollport
- The grid is positioned so that the child item wouldn't appear if it were relatively positioned (e.g.
left: -100000px
) - 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.
(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:
- An element with
display: grid
is appended to the parent - The grid has a child item with sticky positioning, and the parent is the scrollport
- The grid is positioned so that the child item wouldn't appear if it were relatively positioned (e.g.
left: -100000px
) - Asynchronously, the grid is moved into view (e.g.
left: 0px;
)
Comment 2•11 months ago
|
||
Comment 3•11 months ago
|
||
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•11 months ago
|
||
At least, I can reproduce the issue on nightly59.0a1(20171201105203) with webrender enabled on windows11....
Updated•11 months ago
|
Comment 5•10 months ago
|
||
The severity field is not set for this bug.
:jwatt, could you have a look please?
For more information, please visit BugBot documentation.
Updated•10 months ago
|
Comment 6•10 months ago
|
||
(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.
Description
•