Created attachment 471712 [details] screen recording of issue Elements visible during transition, disappear after transition, but are still interactive TEST URL https://blog.gingerbeardman.com/2024/06/18/tetris-heavenly-scrolls/ Wait or click to view any of the slides other than the first or last. SETUP - macOS 14.5 - Apple M1 Pro BROKEN (elements disappear after transition) - iOS: Safari 17.5.1 - macOS: Safari 17.5 - macOS: Safari TP 196, 195, 193, 189, 185, 183, 181, 179, 177, 173 WORKING (elements remain visible) - macOS: Chrome 126 - macOS: Opera 110
My workaround is to put: translateZ(0) nto the CSS of the elements that were disappearing. I have no idea why this is required only in Safari. The example URL in the meta data of this issue has been updated to be an archived copy of the problematic site, as I have now rolled out this workaround.
<rdar://problem/130425260>
The arrows and carousel indicator are missing; looks like a z-ordering issue.
The arrows and carousel indicator are missing, but only sometimes; not on the first and last slide and crucially not during the transition itself. Z-ordering does appear to be the case given the workaround.
Removing the wrapping ` c-off-canvas-container` (or removing its transform) is a workaround.
Interesting, thanks. Is there any insight into what the regression or change is that means this is only broken in Safari?
Created attachment 471744 [details] Test reduction
This is a bug in the overlap logic (LayerOverlapMap). In a version of the test case, this is the layer hierarchy: -S---------C-c-- -- -b--h- -gkc-s 9 9 0x179000860 (0,0) width=883 height=1144 [SA 0x104095180] (layerID 466) {sc ProcessQualified(470, 10)} RenderView 0x1790002c0 -S-----------c-- -- -b--h- ---c-- 9 9 + 0x179001680 (0,0) width=883 height=688 [SA 0x104096060] RenderBlock 0x179001520 HTML 0x179006930 -S-----T---C-c-- -- -b--h- -gkcx- 9 9 + 0x179003980 (8,8) width=867 height=672 (layerID 472) RenderBlock 0x179003820 DIV 0x179007160 class='transformed-container' -S-----T---C---t -- ------ -gkcx- 9 9 + 0x179003c30 (492,21) width=54 height=54 (layerID 473) RenderBlock (positioned) 0x179003ad0 DIV 0x1790071e0 class='abspos' -S-----T---C-c-t -- -b--h- -gkcx- 9 9 + 0x179004360 (11,11) width=400 height=600 (layerID 477) graphical effect RenderBlock 0x179004200 DIV 0x1790073c0 class='translated' -S-----T-------t -- ------ -g---- 9 9 + 0x179004610 (0,0) width=402 height=602 RenderBlock (positioned) 0x1790044b0 DIV 0x1790075a0 class='slide' -S-----T---C---t -- ------ -gkcx- 9 9 + 0x1790048c0 (0,0) width=402 height=602 (layerID 476) overlap RenderBlock (positioned) 0x179004760 DIV 0x179007700 class='right slide' -S-------------t -- ------ -g---- 9 9 + 0x1790040b0 (21,21) width=200 height=200 RenderBlock (positioned) 0x179003d80 DIV 0x179007340 class='above' 0x1790040b0 is the green box that ends up underneath (the arrows in the original content). We fail to composite it because we fail to detect that it's above 0x179004610. And that happens because when we add 0x179004610 to the overlap map, we haven't yet determined that 0x179004360 will be composited, which only happens after descendant traversal (in the " // Now check for reasons to become composited that depend on the state of descendant layers" clause). So we add the bounds of 0x179004610 to the overlap map in the scope of 0x179000860 rather than the scope of 0x179004360. This implies that overlap testing is broken whenever we make post-descendant compositing decisions.
Thanks for the extra info. For my own sanity I'd love to know how long it's been like this? I could say it once worked fine, but I can't be sure.
Created attachment 472506 [details] More self-explanatory test case