[Webkit-unassigned] [Bug 220231] New: REGRESSION: animated iframe painted blank

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=220231

            Bug ID: 220231
           Summary: REGRESSION: animated iframe painted blank
           Product: WebKit
           Version: Safari 14
          Hardware: Unspecified
               URL: https://hofman-stripe-payments-demo.appspot.com/?strip
                    eStaticLayer=true&stripeTransitionFix=false
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P1
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: hofman+webkit at stripe.com

Created attachment 416919

  --> https://bugs.webkit.org/attachment.cgi?id=416919&action=review

Screen capture of the reproduction of the CSS animation bug

We have a couple iframe paint bugs in Safari we've finally been able to consistently reproduce on some systems.

In Safari 13+ (and possibly earlier versions), a loaded iframe faded into view through a JavaScript based animation (e.g. `$.fadeIn()`) would sometimes paint blank. In those cases, no composite layer for the iframe would exist. Any reflow of the container would trigger the iframe paint. Applying a transform or other CSS style that would force a composite layer for the iframe would prevent the occurrence of this bug.

To reproduce:
- In Safari 13+ , open https://hofman-stripe-payments-demo.appspot.com/jq-repro/?stripeStaticLayer=false&stripeTransitionFix=false
- Click CB (the frame is painted correctly)
- Refresh
- Click CB again (make sure network cache is not disabled if devtools are open)
- Observe blank painted iframe where card input should be
- The iframe is actually functional, can be filed through keyboard or autofill.
- Any resize of the container (window) caused the iframe to be painted


However, the workaround to force a composite layer through CSS style causes another blank paint bug in Safari 14+. If the loaded iframe is animated into view through a CSS transition on an ancestor, the iframe is painted blank. Without the forced promotion to its own composition layer, the iframe would render fine. A forced reflow of the parent doesn't help repaint the iframe since it has its own composite layer. We have implemented another workaround to listen for transition start events on any ancestor and force a reflow on the iframe itself, however it's very hacky, and we are worried of other undiscovered cases where this bug might trigger.

To reproduce:
- In Safari 14+, open https://hofman-stripe-payments-demo.appspot.com/?stripeStaticLayer=true&stripeTransitionFix=false
- Observe the card iframe painted blank
- The iframe is actually functional, can be filed through keyboard or autofill.


We've had multiple bug reports from our users about these issues including:
- https://github.com/stripe/react-stripe-js/issues/136
- https://github.com/stripe/stripe-js/issues/128
- https://github.com/stripe/stripe-js/issues/113
- https://github.com/stripe/react-stripe-elements/issues/35

While the above reproductions are for desktop Safari, we've had reports of these bugs also happening on iPhone and iPad.

There are some triggers we still don't fully understand. For the first reproduction, we don't know why caching seem to have an impact. For the second reproduction, the issue only manifests if the iframe has loaded before the CSS transition starts (the reproduction delays CSS animation until load for consistency). We unfortunately haven't been able to create more minimal reproductions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210104/76f5c5be/attachment.htm>