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•1 year 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•1 year ago
|
||
Not exactly sure where this should live. Happy to help someone debug.
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Not sure if this is a CSS, layout, or a WR issue.
Comment 6•1 year 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•1 year ago
|
||
Comment 10•1 year 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•1 year 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•1 year ago
|
Comment 12•1 year ago
|
||
Comment 13•1 year ago
|
||
Okay, I've updated the testcase here to be the first one. Can you confirm that this is the correct testcase?
Comment 14•1 year ago
|
||
Botond, I think you've worked on scrolling + perspective before. Do you have any thoughts?
Updated•1 year ago
|
Comment 15•1 year ago
|
||
Triaging as S3, since reporter indicates this is an unusual and not necessarily uncontroversial thing to do.
Updated•1 year ago
|
| Reporter | ||
Comment 16•1 year 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•1 year 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•1 year ago
|
Comment 18•1 year 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•1 year ago
|
||
Updated•1 year ago
|
Comment 20•1 year ago
|
||
Comment 21•1 year 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
•