Created attachment 373001 [details] testcase Steps to reproduce: 1. extract the test case attached 2. use a web server to serve it, e.g. python3 -mhttp.server 3. open the page in browser via the server 4. click the fullscreen button on the bottom of the page (you may not see the button at its initial load, but a further reload should get it right) Expected result: the result shows as is Actual result: the dot before "TITLE 3" disappears This seems to be related to the two <canvas> elements on the page. If I remove both then the dot appears again. This issue happens on Chrome as well, and I've filed: https://bugs.chromium.org/p/chromium/issues/detail?id=979103 Sorry about the large testcase. I haven't figured out a way to reduce it properly. This can also reproduce on our product website directly: https://www.canva.com/design/DADd7-c0PH4/iKHgh3or0fXnqueYWPj2Gg/view?utm_content=DADd7-c0PH4&utm_campaign=designshare&utm_medium=link&utm_source=sharebutton (although we may try fixing it from our side as well, so it may no longer reproducible there after several weeks).
<rdar://problem/52269637>
I think the element disappears because it's composited, and we think it's outside the bounds of the viewport (but we're using the non-fullscreen viewport).
FWIW, this seems to happen when there is <video> (rather than <canvas>) as well.
Adding `backface-visibility: hidden` to disappearing elements fixes the issue. Can be used as a workaround.
Created attachment 385732 [details] minimized testcase Thanks to Alexander Polyankin, here's a minimized testcase, which involves video instead of canvas. This should help you diagnose the issue I hope.
Created attachment 385733 [details] minimized testcase using canvas
I don't see how to go fullscreen with that test case.
You don't need to go fullscreen in that testcase to reproduce the issue.
In the new minimized test, there is a <video> or <canvas> which containing a large red block, and a <div> with a green block which is supposed to wholly cover the red block. In WebKit (and Blink), <video> and <canvas> would be promoted to the topmost covering the <div> regardless of z-order they are supposed to be.
Looks like an overlap testing bug.
Hi Simon & team, Is there any progress on this issue? The `backface-visibility: hidden` workaround is causing quite a few performance issue on iOS. It triggers hardware acceleration and promotes to a new composite layer. It is even worse if you have another elements overlapping this new layer by consuming too much GPU memory. Could you please let us know if there are any workarounds or plans to fix this issue? Thanks!
Created attachment 461130 [details] Simpler testcase
The bug here is that in RenderLayerCompositor::addToOverlapMap() we're comparing a transformed layer bounds with a non-transformed clip rect. RenderLayerCompositor::computeExtent() takes ancestor transforms into account when mapping them to absolute coordinates via overlapMap.geometryMap().absoluteRect(layerBounds) - all rects in the overlap map are absolute. But RenderLayerCompositor::addToOverlapMap() gets the clipRect via layer.backgroundClipRect() which ignores transforms.
Hi Simon, are you suggestion that the clip layer(one with overflow:hidden) is not scaled so it will only display anything within that 100*100px area? If that's correct, do you have any plan on fixing this? This is very interesting bug by the way. Thanks!