Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: eab78766e024f6411cb60e10a3ed18b84e84aa30
https://github.com/WebKit/WebKit/commit/eab78766e024f6411cb60e10a3ed18b84e84aa30
Author: Alex Christensen <[email protected]>
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@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
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
