[webkit-changes] [WebKit/WebKit] d1284d: Insert RemoteFrameView into render tree when repla...

Alex Christensen noreply at github.com
Wed Jan 11 18:08:38 PST 2023


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d1284d186bc0f4cc55f756ae2e7981130d4c7cc4
      https://github.com/WebKit/WebKit/commit/d1284d186bc0f4cc55f756ae2e7981130d4c7cc4
  Author: Alex Christensen <achristensen at apple.com>
  Date:   2023-01-11 (Wed, 11 Jan 2023)

  Changed paths:
    M Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
    M Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.h
    M Source/WebKit/WebProcess/WebCoreSupport/WebRemoteFrameClient.cpp
    M Source/WebKit/WebProcess/WebCoreSupport/WebRemoteFrameClient.h
    M Source/WebKit/WebProcess/WebPage/WebFrame.cpp

  Log Message:
  -----------
  Insert RemoteFrameView into render tree when replacing a FrameView
https://bugs.webkit.org/show_bug.cgi?id=250466
rdar://104131312

Reviewed by Tim Horton.

In Frame::createView we call RenderWidget::setWidget so that the frame is drawn.
When removing the Frame and replacing it with a RemoteFrame, we used to get garbage
pixels drawn to the screen and lots of errors saying this:
"ERROR: called FrameView::paint with nil renderer"

To fix this we need to add a corresponding call to RenderWidget::setWidget with the
RemoteFrameView.  When this happens, though, the WebFrameLoaderClient is destroyed
which would call WebFrame::invalidate then cause all the tests to time out because
the UI process though there was no more frame.  To fix this problem I introduce a
ScopeExit that calls WebFrame::invalidate upon destruction, and I transfer
this object between the WebFrameLoaderClient and the corresponding equivalent for
RemoteFrames, the WebRemoteFrameClient.  This properly keeps the UI process informed
when the frame is actually destroyed but not when it has been converted to a remote
frame, about which the UI process is already aware.

After this PR a RemoteFrame no longer shows garbage pixels, but instead shows a white
rectangle, which is a step in the right direction.  Drawing colors in
RemoteFrameView::paintContents also does show to the screen, which indicates we are
also heading in the right direction.  A following step in this direction will be to
make layers and stitch them together in the UI process to actually show the iframe
content in the right location instead of just a blank rectangle.

* Source/WebKit/Sources.txt:
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::WebFrameLoaderClient):
(WebKit::WebFrameLoaderClient::takeFrameInvalidator):
(WebKit::WebFrameLoaderClient::~WebFrameLoaderClient): Deleted.
* Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.h:
* Source/WebKit/WebProcess/WebCoreSupport/WebRemoteFrameClient.cpp:
(WebKit::WebRemoteFrameClient::WebRemoteFrameClient):
* Source/WebKit/WebProcess/WebCoreSupport/WebRemoteFrameClient.h:
* Source/WebKit/WebProcess/WebPage/WebFrame.cpp:
(WebKit::WebFrame::didCommitLoadInAnotherProcess):

Canonical link: https://commits.webkit.org/258813@main




More information about the webkit-changes mailing list