| Summary: | REGRESSION: animated iframe painted blank | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Mathieu Hofman <hofman+webkit> |
| Component: | Animations | Assignee: | Simon Fraser (smfr) <simon.fraser> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | andybons, dino, graouts, simon.fraser, webkit-bug-importer, zalan |
| Priority: | P1 | Keywords: | InRadar |
| Version: | Safari 14 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://hofman-stripe-payments-demo.appspot.com/?stripeStaticLayer=true&stripeTransitionFix=false | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=220498 | ||
| Attachments: | |||
|
Description
Mathieu Hofman
2021-01-03 18:52:11 PST
Created attachment 416920 [details]
Screen capture of the reproduction of the Javascript animation bug
> - In Safari 13+ , open https://hofman-stripe-payments-demo.appspot.com/jq-repro/?stripeStaticLayer=false&stripeTransitionFix=false I can reproduce this issue with a recent WebKit build that I have on my machine. > - In Safari 14+, open https://hofman-stripe-payments-demo.appspot.com/?stripeStaticLayer=true&stripeTransitionFix=false But I cannot reproduces this one. Perhaps it's a Safari 14 regression that's been fixed already. > But I cannot reproduces this one. Perhaps it's a Safari 14 regression that's been fixed already.
Apparently we still have inconsistent reproduction on this depending on the machine. We're trying to figure out if there is some other factor (e.g. dedicated graphics).
Can you reproduce in Safari 14.0.2 (15610.3.7.1.10, 15610)? My machine is a MacBookPro15,2 i7 running macOS 10.15.7 (19H15)
Created attachment 416961 [details]
iframe painted when window dragged to built-in display
Created attachment 416963 [details]
iframe not painted when window dragged to other display
I believe we've isolated a necessary trigger for this bug: the window needs to be rendered on a secondary display (non-retina?), not the built-in display of the MacBook Pro. Then dragging that window to the built-in display will cause the iframe to be painted. The same is not true if dragging the window to another (non-retina?) display. I've verified that rendering on a secondary retina monitor does not trigger this bug. It seems that the trigger for the CSS animation based bug is for the window to be rendered on a non-retina display. I can reproduce the Safari 14 version on a non-retina display. I can see that the GraphicsLayers are connected across frame boundaries, but the CALayers are not. Doesn't happen if we don't call m_graphicsLayer->setContentsVisible(false) on the iframe's layer. Hardcoding the deviceScaleFactor() to 1 makes it happen on Retina screens. Found it. The "non-retina" part is related to m_compositedBoundsOffsetFromGraphicsLayer which affects whether the iframe's GraphicsLayer uses a m_contentsClippingLayer or not. Created attachment 417044 [details]
Patch
Committed r271191: <https://trac.webkit.org/changeset/271191> All reviewed patches have been landed. Closing bug and clearing flags on attachment 417044 [details]. Thanks for the quick turnaround. For clarification, does the patch also fix the JavaScript based animation bug present since at least Safari 13? Sorry for filing a combined bug on this one, they seemed related since our workaround for the first one triggered the second one. The Safari 13+ bug does seem to still reproduce after this fix. I'll investigate. Doing so in bug 220498. |