weird transformations when scrolled with perspective+position sticky
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
People
(Reporter: va9iff, Unassigned)
Details
Attachments
(4 files, 2 obsolete files)
Steps to reproduce:
use sticky position for 3d rotated elements with perspective
Actual results:
scrolling it rotated even further, then flashed back
Expected results:
nothing. sticky element should have acted like a normal sticky element. this bug doesn't happen on chrome btw. for firefox mobile (android) bug still persists
Comment 1•20 days ago
|
||
The Bugbug bot thinks this bug should belong to the 'Fenix::General' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
From the linked article:
CSS:
#container {
overflow: scroll;
height: 200px;
}
#space {
position: sticky;
top: 0;
perspective: 300px;
}
#object {
transform: rotateX(45deg)
}
#content {
height: 400%;
}
/*
visual styles
*/
#container {
background-color: #222;
display: flex;
flex-direction: row-reverse;
padding: 30px;
}
#object {
background-color: #888;
text-align: center;
border-radius: 16px;
width: 140px;
height: 140px;
}
#content {
color: #eee;
padding: 30px;
}
HTML:
<div id="container">
<div id="space">
<div id="object">solid</div>
</div>
<div id="content">
hjkl<br>hjkl<br>hjkl<br>hjkl<br>hjkl<br>hjkl<br>
hjkl<br>hjkl<br>hjkl<br>hjkl<br>hjkl<br>hjkl<br>
</div>
</div>
(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #1)
The Bugbug bot thinks this bug should belong to the 'Fenix::General' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Perhaps the reporter didn't report it well, but Bugbot is wrong. This is not a Fenix bug. It's a Firefox bug.
Comment 4•19 days ago
|
||
Not exactly sure where this should live. Happy to help someone debug.
Updated•19 days ago
|
Comment 5•18 days ago
|
||
Not sure if this is a CSS, layout, or a WR issue.
Comment 6•18 days ago
|
||
Hard to know for sure - we will probably want to take a look at the display list produced by Gecko, and see if that looks correct, which will let us know whether it's a WR bug or something in layout. Tim might be able to look at the DL for this?
I've found a very strange workaround. when I apply overflow: scroll
and perspective
to the same element, the transformations inside the sticky childs of this element works properly
https://stackoverflow.com/a/79379282/16060585 (btw I'm the OP of the question and the answer)
css
#container {
overflow: scroll;
height: 200px;
perspective: 300px;
}
#space {
position: sticky;
top: 0;
}
#object {
transform: rotateX(45deg)
}
#content {
height: 400%;
}
/*
visual styles
*/
#container {
background-color: #222;
display: flex;
flex-direction: row-reverse;
padding: 30px;
}
#object {
background-color: #888;
text-align: center;
border-radius: 16px;
width: 140px;
height: 140px;
}
#content {
color: #eee;
padding: 30px;
}
html
<div id="container">
<div id="space">
<div id="object">solid</div>
</div>
<div id="content">
hjkl<br>hjkl<br>hjkl<br>hjkl<br>hjkl<br>hjkl<br>
hjkl<br>hjkl<br>hjkl<br>hjkl<br>hjkl<br>hjkl<br>
</div>
</div>
actually, sorry. the snippet there is flawed and doesn't work properly. I missreplicated. the actual snippet is updated here https://stackoverflow.com/a/79379282/16060585 this place doesn't let me update apparently
Comment 9•17 days ago
|
||
Comment 10•17 days ago
|
||
(In reply to Vagif from comment #8)
actually, sorry. the snippet there is flawed and doesn't work properly. I missreplicated. the actual snippet is updated here https://stackoverflow.com/a/79379282/16060585 this place doesn't let me update apparently
I copied the testcase from that link and attached it here to this bug as container.html, can you confirm that the html file I attached here shows the issue that you are reporting?
Reporter | ||
Comment 11•16 days ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #10)
yeah but that's a dirty workaround. I want the one on the question, with no scrolling change. you are pasting the snippet from my answer which doesn't solve the problem. it was just a tip for you guys to investigate better. cuz in this case the bug wasn't occurring but that's very limited workaround and the actual bug still persists
Updated•16 days ago
|
Comment 12•16 days ago
|
||
Comment 13•16 days ago
|
||
Okay, I've updated the testcase here to be the first one. Can you confirm that this is the correct testcase?
Comment 14•10 days ago
|
||
Botond, I think you've worked on scrolling + perspective before. Do you have any thoughts?
Updated•10 days ago
|
Comment 15•10 days ago
|
||
Triaging as S3, since reporter indicates this is an unusual and not necessarily uncontroversial thing to do.
Updated•10 days ago
|
Reporter | ||
Comment 16•2 days ago
|
||
"Enhancement" ? it's a bug that causes transformation to behave incorrectly. I'm gonna be honest with you, Erich, your response is just like making an excuse so that the issue can be dismissed for now. I may be wrong about that, but that's the vibe I got
Comment 17•2 days ago
|
||
Here is a further simplified version of the testcase.
Steps to reproduce
Scroll the page.
Expected results
The green trapezoid should not move or change shape.
Actual results
The green trapezoid changes shape as you scroll, but then snaps back to its original shape as soon as you trigger a repaint (e.g. with a mouse click).
I agree it's a bug. I suspect it's most likely to be an issue in the WebRender frame building logic for updating transforms in response to scrolling (around here).
Updated•2 days ago
|
Comment 18•2 days ago
|
||
I have more specifically tracked down the bad transform to this line:
// Do a change-basis operation on the
// perspective matrix using the scroll offset.
source_transform
.pre_translate(scroll_offset)
.then_translate(-scroll_offset)
This is performing some sort of adjustment to the perspective matrix to account for scrolling that applies to the transformed content. However, in this case the transformed content is inside a sticky element that's currently in the "stuck" state so scrolling doesn't actually apply to it.
Comment 19•2 days ago
|
||
Updated•2 days ago
|
Comment 20•2 days ago
|
||
Comment 21•2 days ago
|
||
I don't understand what the affected code is trying to do well enough to suggest a fix off the top of my head, and I don't have the cycles to take a deeper dive into this right now, but hopefully comment 18 is helpful in confirming this as a WebRender issue and pointing to the place to investigate further. I've also attached a (failing) reftest to make further investigation easier.
Description
•