Bug 220498 – Stripe payment subframe contents missing sometimes

• Component: Compositing
• Status: NEW

[Simon Fraser (smfr)]

From bug 220231:

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

[Simon Fraser (smfr)]

<rdar://problem/72854595>

[Simon Fraser (smfr)]

These test pages are continually running requestAnimation frame when nothing is happening. That's very bad for battery life.

[Simon Fraser (smfr)]

We've got layers with stray dirty bits:


S---------C---- -- t----- ------ 11 11 0x15dc7fa10 (0,0) width=1291 height=1109 (layerID 88) {sc 5} RenderView 0x1119e9270
S-------------- z- t----- ------ 11 11   + 0x14d6d4cf0 (0,0) width=1291 height=590 RenderBlock 0x14a8cae20 HTML 0x14b162ee0
--------------- -- ------ ------ 11 11     + 0x14d6d4e60 (312.16,32) width=666 height=482 RenderBlock (floating) 0x14a8cb2a0 DIV 0x14ce07c00 class='col-sm-8 col-sm-offset-2'
S--A----------- zn ------ ------ 11 11     + 0x14b9e6170 (35,20) width=597 height=432 RenderBlock 0x14cdf0ea0 DIV 0x14a8a4500 id='credit-card' class='active'
--------------- -n ------ ------ 11 11       + 0x14bc14b80 (-15,10) width=627 height=74 RenderBlock (floating) 0x14cdf0a20 DIV 0x14a8a4600 class='col-md-12 col-sm-12'
--------------- -n ------ ------ 11 11       + 0x14bc14450 (-15,89) width=366 height=167 RenderBlock (floating) 0x14cdf06c0 DIV 0x14a8a4700 class='col-md-7 col-sm-12'
--------------- -n ------ ------ 11 11       + 0x14bc145c0 (5,10) width=361 height=49 RenderBlock (floating) 0x14cdf0480 DIV 0x14a8a4800 class='col-md-12 col-sm-12'
--------------- -n ------ ------ 11 11       + 0x14d6bbb80 (5,64) width=361 height=49 RenderBlock (floating) 0x14cdf0240 DIV 0x14a8a4900 class='col-md-12 col-sm-12'
--------------- -n t----- ------ 11 11       + 0x14bc90000 (25,15) width=311 height=24 RenderBlock (relative positioned) 0x14a8ca2e0 DIV 0x14a8a5900 class='__PrivateStripeElement'
-N------------- -n ------ l----- 11 11         n 0x14bbba5c0 (0,0) width=311 height=24 RenderIFrame 0x14b1615c0 IFRAME 0x15fca94b0

Looks like layer 0x14d6d4e60 was inserted after 0x14bbba5c0 got dirtied, and left a gap in the chain of dirty bits.

[Simon Fraser (smfr)]

^ 0x14b9e6170 was inserted

[Simon Fraser (smfr)]

The iframe is created via script. At some point we call RenderLayerCompositor::layerStyleChanged() which calls layer.setNeedsPostLayoutCompositingUpdate(); for the iframe's layer, but the layer tree is not fully constructed here so RenderLayer::setAncestorsHaveCompositingDirtyFlag() doesn't have a valid paint order tree in which to set dirty bits.

[Mathieu Hofman]

> continually running requestAnimation frame when nothing is happening. That's very bad for battery life.

Apparently this is an old workaround we've had for internal size calculations. Thanks for pointing it out, we'll look into removing that. It wouldn't have an impact on this rendering bug, right?