220498 2021-01-09 12:13:05 -0800 Stripe payment subframe contents missing sometimes 2022-04-23 19:34:11 -0700 1 1 1 Unclassified WebKit Compositing Safari Technology Preview Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=220231 InRadar P2 Normal --- 1 simon.fraser simon.fraser andybons hofman+webkit kzpsmm275395 simon.fraser webkit-bug-importer oldest_to_newest 1718577 0 simon.fraser 2021-01-09 12:13:05 -0800 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 1718578 1 simon.fraser 2021-01-09 12:14:30 -0800 <rdar://problem/72854595> 1718579 2 simon.fraser 2021-01-09 12:16:02 -0800 These test pages are continually running requestAnimation frame when nothing is happening. That's very bad for battery life. 1718580 3 simon.fraser 2021-01-09 13:44:44 -0800 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. 1718581 4 simon.fraser 2021-01-09 13:45:07 -0800 ^ 0x14b9e6170 was inserted 1718583 5 simon.fraser 2021-01-09 14:21:04 -0800 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. 1718743 6 hofman+webkit 2021-01-11 10:58:34 -0800 > 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?