commit 76f41a5c24c36011c5251dd96694342381231a2c
author Daniel Libby <dlibby@microsoft.com> Thu Jun 04 00:22:05 2020
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Thu Jun 04 00:43:10 2020
tree 4ff0c9a55ef8c564c5d9c78ac9ae0ee7beba94ee
parent 7810613a0254e37a268cbf20058c4a249daa5ecc

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/+/2227897
Reviewed-by: Stefan Zager <szager@chromium.org>
Commit-Queue: Daniel Libby <dlibby@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#774868}