Repaint remote frames when new layer is set #23930
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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}