Bug 199258

Summary: Some elements disappear when there is a video or canvas inside a scaled overflow:hidden ancestor
Product: WebKit Reporter: Xidorn Quan <xidorn-webkit>
Component: CompositingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WORKSFORME    
Severity: Normal CC: bfulgham, codyzhao, dino, jer.noble, ranquild, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: CanvaBug, InRadar
Version: Safari Technology Preview   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
testcase
none
minimized testcase
none
minimized testcase using canvas
none
Simpler testcase none

Xidorn Quan
Reported 2019-06-26 21:50:30 PDT
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).
Attachments
testcase (1.07 MB, application/zip)
2019-06-26 21:50 PDT, Xidorn Quan
no flags
minimized testcase (3.86 KB, text/html)
2019-12-15 20:12 PST, Xidorn Quan
no flags
minimized testcase using canvas (936 bytes, text/html)
2019-12-15 20:16 PST, Xidorn Quan
no flags
Simpler testcase (735 bytes, text/html)
2022-07-21 19:59 PDT, Simon Fraser (smfr)
no flags
Radar WebKit Bug Importer
Comment 1 2019-06-27 10:43:56 PDT
Simon Fraser (smfr)
Comment 2 2019-06-27 10:46:32 PDT
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).
Xidorn Quan
Comment 3 2019-11-28 22:20:06 PST
FWIW, this seems to happen when there is <video> (rather than <canvas>) as well.
Alexander Polyankin
Comment 4 2019-11-28 22:39:16 PST
Adding `backface-visibility: hidden` to disappearing elements fixes the issue. Can be used as a workaround.
Xidorn Quan
Comment 5 2019-12-15 20:12:56 PST
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.
Xidorn Quan
Comment 6 2019-12-15 20:16:40 PST
Created attachment 385733 [details] minimized testcase using canvas
Simon Fraser (smfr)
Comment 7 2019-12-16 15:34:49 PST
I don't see how to go fullscreen with that test case.
Xidorn Quan
Comment 8 2019-12-16 16:01:59 PST
You don't need to go fullscreen in that testcase to reproduce the issue.
Xidorn Quan
Comment 9 2019-12-18 14:46:29 PST
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.
Simon Fraser (smfr)
Comment 10 2019-12-18 15:05:28 PST
Looks like an overlap testing bug.
cody zhao
Comment 11 2022-07-21 19:15:54 PDT
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!
Simon Fraser (smfr)
Comment 12 2022-07-21 19:59:10 PDT
Created attachment 461130 [details] Simpler testcase
Simon Fraser (smfr)
Comment 13 2022-07-21 20:20:05 PDT
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.
cody zhao
Comment 14 2022-07-21 20:58:23 PDT
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!
Xidorn Quan
Comment 15 2024-12-11 20:57:12 PST
This issue seems to have been fixed.
Note You need to log in before you can comment on or make changes to this bug.