[webkit-changes] [WebKit/WebKit] eab787: Make window.open use correct process when called f...

Alex Christensen noreply at github.com
Mon Mar 25 11:30:27 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: eab78766e024f6411cb60e10a3ed18b84e84aa30
      https://github.com/WebKit/WebKit/commit/eab78766e024f6411cb60e10a3ed18b84e84aa30
  Author: Alex Christensen <achristensen at apple.com>
  Date:   2024-03-25 (Mon, 25 Mar 2024)

  Changed paths:
    M LayoutTests/platform/mac-site-isolation/TestExpectations
    M Source/WebKit/UIProcess/API/APIPageConfiguration.cpp
    M Source/WebKit/UIProcess/API/APIPageConfiguration.h
    M Source/WebKit/UIProcess/API/C/WKPageConfigurationRef.cpp
    M Source/WebKit/UIProcess/API/C/WKPageConfigurationRef.h
    M Source/WebKit/UIProcess/Cocoa/UIDelegate.mm
    M Source/WebKit/UIProcess/WebPageProxy.cpp
    M Source/WebKit/UIProcess/WebProcessPool.cpp
    M Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm

  Log Message:
  -----------
  Make window.open use correct process when called from a site isolated iframe
https://bugs.webkit.org/show_bug.cgi?id=271514

Reviewed by Charlie Wolfe.

When JS calls window.open, WebPageProxy::createNewPage gives an API::PageConfiguration
(which is now equivalent to a WKWebViewConfiguration) to the UIClient containing state
that must be used to make the new WKWebView.  Before site isolation, that state was just
the related page, whose process must be shared to keep functionality working such as
iframes with the same origin as the opener being able to directly access the opener's DOM.
With site isolation, the state that is needed to keep this functionality working is the
BrowsingContextGroup, which contains the maps of domains to processes, and the opener
frame identifier, which needs to be used to put the opened frame initially in the same
process as the opener while the opened frame contains only about:blank.  From about:blank
it can then use the BrowsingContextGroup to navigate to the correct process for any domain.

Unfortunately, though, there is SPI to do tricky things with the related page, and
WebKitTestRunner uses this SPI to retrofit an unrelated WKWebViewConfiguration into looking
enough like the suggested WKWebViewConfiguration that WebKit accepts it and uses it correctly.
In order to keep this working, I needed to make additional SPI to copy the site isolation
state from one WKPageConfigurationRef to another.  Conveninetly, WKPageConfigurationRef
can now be converted to WKWebViewConfiguration using toll-free-bridging.

It looks like all that work I did over the last week to clean up WKWebViewConfiguration
is already paying off!

I verified this fixes http/tests/site-isolation/iframe-and-window-open.html
but only how we used to run it before 276416 at main.  Additional work is being done
on our strategy for running existing layout tests to verify site isolation correctness.

* LayoutTests/platform/mac-site-isolation/TestExpectations:
* Source/WebKit/UIProcess/API/APIPageConfiguration.cpp:
(API::PageConfiguration::setBrowsingContextGroup):
(API::PageConfiguration::openerFrameID const):
(API::PageConfiguration::setOpenerFrameID):
* Source/WebKit/UIProcess/API/APIPageConfiguration.h:
* Source/WebKit/UIProcess/API/C/WKPageConfigurationRef.cpp:
(WKPageConfigurationCopySiteIsolationState):
* Source/WebKit/UIProcess/API/C/WKPageConfigurationRef.h:
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::createNewPage):
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::createWebPage):
* Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:
(WTR::TestController::platformCreateOtherPage):

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



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications


More information about the webkit-changes mailing list