Depth sorting with z-transform differs from other browsers

• Component: Layout and Rendering
• Status: RESOLVED CONFIGURATION CHANGED

[Ashley Gullen]

The new Web Animations API support in the latest Safari Technology Previews renders incorrectly with our PWA. We've added a special "slow animations" mode to better demonstrate what is happening. There appear to be several different bugs with it.

Note any comparisons to Firefox are using Nightly 63+, since Firefox v62 and prior have a Web Animations bug that also affects our PWA.

Test URL: https://editor.construct.net/r113/?slow-animations

Case A:
1) Open the URL
2) Click 'New project'

Observed result:
A dialog animates in, but during the animation the background dimming layer is rendered on top. When the animation finishes it then switches to rendering the background dimming layer underneath, resulting in a sudden brightening of the dialog.
You can also see other layering problems like some icons underneath the dialog also rendering on top until the animation finishes.

Expected result:
Background dimming layer to render underneath dialog during animation. Appears correctly in Chrome and Firefox 63+.

Case B:
1) Open the URL
2) Click 'New project'
3) Click 'Cancel' on the dialog

Observed result:
Sometimes once the dialog animates out, it briefly appears aligned in the top-left of the window at full opacity. This seems sporadic and doesn't always happen, but does occasionally, particularly after reloading the page.
This is easier to reproduce if you remove ?slow-animations from the URL and repeatedly click "New project" and then press "Escape" to cancel the dialog. For me about one in every five times reproduces the issue.

Expected result:
The dialog element is removed from the document as soon as it finishes the animation. It should never render in between. It works correctly in Chrome and Firefox 63+. (This Safari issue is similar to this Firefox bug affecting Firefox 62 and older: https://bugzilla.mozilla.org/show_bug.cgi?id=1354501)

Case C:
1) Open the URL
2) Click 'New project'
3) Click 'Create'
4) Double-click in the empty space in the main view
5) A dialog fades in. Move it to the left side of the screen, then press 'Cancel'.

Observed result:
The main view is rendered using a canvas element. When the dialog animation is running, the parts of the dialog element that overlap the canvas are invisible, as demonstrated by this screenshot: https://www.dropbox.com/s/sechnwsixnoti48/Screen%20Shot%202018-08-16%20at%2016.36.45.png?dl=0

If the dialog element overlaps the canvas element entirely, it is completely invisible for the duration of the animation.

Expected result:
Dialog to always appear no matter what it is overlapping. Renders correctly in Chrome and Firefox 63+.

[Radar WebKit Bug Importer]

<rdar://problem/43406424>

[Ashley Gullen]

All three cases still reproduce for me in TP 65.

[Ashley Gullen]

All three cases still reproduce in TP 70.

[Ashley Gullen]

I can still reproduce case A and case C in Safari TP 80 with the latest version of our web app at https://editor.construct.net/r147/?slow-animations

Please don't ship broken Web Animations!

[Ashley Gullen]

The release notes to TP 83 include fixes to rendering, but all cases mentioned here still reproduce.

[Ashley Gullen]

Safari TP 96 enables Web Animations by default, and it's still mostly broken.

Updated repro URL: https://editor.construct.net/r176/?slow-animations

Case A: still reproduces
Case B: appears to now be fixed
Case C: still reproduces

Please don't ship broken Web Animations!

[Antoine Quint]

Hi Ashley. It would help a great deal if you could provide reductions for the issues you find so that we don't have to diagnose your entire app.

[Antoine Quint]

I cannot reproduce case B.

I can however reproduce case A, it seems the <dialog> element that is created is stacked below its immediate previous sibling (<div class="c3-dimmer" polyfill></div>) and also behind the little cloud icons that are provided using a :before pseudo-element (#startPageWrap .thumbnailWrap:before) and with a z-index. In fact the little clouds are always stacked above the dimmer. Cc'ing Simon Fraser who might want to look into this issue which may not be related to Web Animations.

I can reproduce case C and I think it might be the same issue as case A, it's a stacking order problem.

I cannot reproduce neither case A nor case C with Firefox.

[Antoine Quint]

A good way to reproduce the stacking issue is to load https://editor.construct.net/r113/?slow-animations, inspect <div class="c3-dimmer" polyfill></div> and set its background-color to have a much higher alpha channel. This really makes it clear that the little clouds aren't stacked as expected.

The Layers tab also shows there are four child layers under <body>: two for clouds, one for <div class="c3-dimmer" polyfill></div> and one for <dialog>.

[Simon Fraser (smfr)]

This isn't about animations (directly); this is about 3D transforms and depth sorting.

The animation keyframes used to show the dialog have a translate3d(x, y, -20px) as the first or last keyframe. In WebKit, this causes the animation to be depth-sorted below the dimmer.

The fix is to remove the -20px; use a scale instead of a perspective animation.

[Antoine Quint]

So our behavior is correct then Simon? Is there a standards-related issue here about compatibility? Firefox doesn't behave the same way.

[Simon Fraser (smfr)]

This is all about how the 3d transforms spec is in flux and we don't adhere to the current draft.

[Ashley Gullen]

I hadn't checked this for a while but it appears to now be working correctly in Safari 17.1.