GitLab

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}