Repaint remote frames when new layer is set
Remote frames in CAP can end up incorrectly sized 0,0 on initial render which makes the iframes content not show up. The initial RenderFrameProxy::SynchronizeVisualProperties can come in before the RemoteFrameView has updated its compositing rect, which leaves the created SurfaceLayer with a 0,0 size. The RemoteFrameView compositing rect is only updated after Paint in the document lifecycle (see LocalFrameView::UpdateLifecyclePhasesInternal) and RenderFrameProxy::SynchronizeVisualProperties is called during intersection observer steps (also after paint). Since the synchronized properties have changed, a new SurfaceLayer is created at the correct size. When setting this SurfaceLayer on RemoteFrame, the existing invalidation of SetNeedsCompositingUpdate is not sufficient in CAP to have a new frame generated with the updated layer. In pre-CAP, this is not an issue - the oopif content appears with the first frame produced due to the ContentsLayer size update via CompositedLayerMapping::UpdateContentsRect in the compositing phase of the document lifecycle. To fix this for CAP, we add a SetNeedsPaint on the frame owner element's paint layer, and schedule another frame to ensure this gets picked up, since these updates typically will come in outside of the document lifecycle. R=pdr@chromium.org Bug: 1078255 Change-Id: I7333a79b3cfbca303fe388bea6d7df176b0e1f41 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2227897Reviewed-by:Stefan Zager <szager@chromium.org> Commit-Queue: Daniel Libby <dlibby@microsoft.com> Cr-Commit-Position: refs/heads/master@{#774868}
Showing
Please register or sign in to comment