-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Fix broken z-ordering on pages with "position: sticky" #46930
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
EWS run on previous version of this PR (hash 0b5336e) |
0b5336e
to
9bd39bc
Compare
EWS run on previous version of this PR (hash 9bd39bc) |
9bd39bc
to
4032537
Compare
EWS run on previous version of this PR (hash 4032537) |
4032537
to
4a793be
Compare
EWS run on previous version of this PR (hash 4a793be) |
4a793be
to
29090bd
Compare
EWS run on previous version of this PR (hash 29090bd) |
29090bd
to
2220211
Compare
EWS run on previous version of this PR (hash 2220211) |
2220211
to
0e2a654
Compare
EWS run on previous version of this PR (hash 0e2a654) |
I removed a test because I ran out of ideas for how to make one that isn’t flaky across all runners. the closest one I got that fails only on mac-wk1 by returning empty string from <!DOCTYPE html>
<html>
<head>
<style>
.sticky {
position: sticky;
top: 0;
width: 100px;
height: 100px;
background: green;
}
.box {
position: relative;
height: 200px;
height: 200px;
background: blue;
}
</style>
<script>
if (window.testRunner) {
testRunner.dumpAsText();
}
function doTest() {
if (window.testRunner) {
document.getElementById('result').innerText = internals.layerTreeAsText(document);
}
}
window.addEventListener('load', doTest, false);
</script>
</head>
<body>
<div class="container">
<div class="sticky"></div>
<div class="box">This element should be composited</div>
</div>
<pre id="result"></pre>
</body>
</html> expectation:
I also tried another approach by doing a ref-test but it ended up being even more fragile, because it has to force layout tree built, then do scrolling in such way that overlap testing is not performed ( |
It looks like we just don't get compositing for sticky in this case with WK1, and without any composited layers, the dump returns empty. I'll wait to see if Simon can review the actual code change, he's much more versed in the sticky code than I am. |
0e2a654
to
f5081a0
Compare
EWS run on previous version of this PR (hash f5081a0) |
f5081a0
to
d2f5616
Compare
EWS run on previous version of this PR (hash d2f5616) |
d2f5616
to
b8e8439
Compare
EWS run on previous version of this PR (hash b8e8439) |
https://bugs.webkit.org/show_bug.cgi?id=238127 Reviewed by NOBODY (OOPS!). Sticky elements could move around without recomputing overlap extent, which leads to incorrect z-ordering when a sticky element moves onto an element that would otherwise be promoted to be composited for indirect "overlap" reason. The bug is fixed using the same approach applied in 5b652c3 to "position: fixed" elements: expanding overlap extent to cover all possible sticky positions. Bug 238127 mentioned CSS grids, but the issue turned out to be more general and at least applies to all sticky elements whose containing block is the root element. * LayoutTests/compositing/layer-creation/sticky-overlap-extent-expected.txt: Added. * LayoutTests/compositing/layer-creation/sticky-overlap-extent.html: Added. * LayoutTests/platform/mac-wk1/TestExpectations: * Source/WebCore/page/scrolling/ScrollingConstraints.cpp: (WebCore::StickyPositionViewportConstraints::computeStickyExtent const): * Source/WebCore/page/scrolling/ScrollingConstraints.h: * Source/WebCore/rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::computeExtent const):
b8e8439
to
44f0532
Compare
EWS run on current version of this PR (hash 44f0532) |
0b5336e
44f0532
🛠 playstation