Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 025e1d2fda31b65326961d5c99039356b2eb7ece
https://github.com/WebKit/WebKit/commit/025e1d2fda31b65326961d5c99039356b2eb7ece
Author: Alex Christensen <achristen...@apple.com>
Date: 2024-05-10 (Fri, 10 May 2024)
Changed paths:
M Source/WebKit/UIProcess/RemotePageProxy.cpp
M Source/WebKit/UIProcess/RemotePageProxy.h
M Source/WebKit/UIProcess/WebFrameProxy.cpp
M Source/WebKit/UIProcess/WebFrameProxy.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp
M Source/WebKit/WebProcess/WebPage/WebFrame.cpp
M Source/WebKit/WebProcess/WebPage/WebFrame.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SiteIsolation.mm
Log Message:
-----------
Begin implementing provisional navigation cancelling with site isolation
https://bugs.webkit.org/show_bug.cgi?id=273971
rdar://127836397
Reviewed by Charlie Wolfe.
When more than two processes are involved, there is an unavoidable time between
when
the UI process tells one web process to start a provisional load and when it
tells another
web process to start another provisional load that the first web process may
have sent a
message to the UI process saying the provisional load has started. If we don't
ignore this
message, the UI process accounting of which frames are in a provisional load
state and in
which process gets messed up. In addition, when starting the second
provisional load, we
need to tell the first provisional load process to destroy its provisional
frame.
I renamed "prepareForProvisionalNavigationInProcess" to
"prepareForProvisionalLoadInProcess"
because "Navigation" is a term we use mostly consistently to refer to a main
frame load.
I renamed "provisionalLoadFailed" to "destroyProvisionalFrame" because it is
now used for
more than just when a provisional load fails. It's now used for when a
provisional load
is intentionally cancelled.
This is just what it took to get the most controlled case of provisional load
cancelling
working reliably with a test. There's still more work to be done in this area,
so I left
a FIXME comment in the test indicating how to test those cases. I think we'll
eventually
have to come up with something better than using
Navigation::currentRequestIsCrossSiteRedirect.
* Source/WebKit/UIProcess/FrameLoadState.cpp:
(WebKit::FrameLoadState::didStartProvisionalLoad):
(WebKit::FrameLoadState::didFailProvisionalLoad):
(WebKit::FrameLoadState::didCommitLoad):
(WebKit::FrameLoadState::didFinishLoad):
(WebKit::FrameLoadState::didFailLoad):
* Source/WebKit/UIProcess/RemotePageProxy.cpp:
(WebKit::RemotePageProxy::didReceiveMessage):
(WebKit::RemotePageProxy::didStartProvisionalLoadForFrame):
* Source/WebKit/UIProcess/RemotePageProxy.h:
* Source/WebKit/UIProcess/WebFrameProxy.cpp:
(WebKit::WebFrameProxy::prepareForProvisionalNavigationInProcess):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::receivedNavigationActionPolicyDecision):
(WebKit::WebPageProxy::continueNavigationInNewProcess):
(WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared):
* Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp:
(WebKit::WebLocalFrameLoaderClient::dispatchDidStartProvisionalLoad):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::loadRequest):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SiteIsolation.mm:
(TestWebKitAPI::TEST(SiteIsolation, CancelProvisionalLoad)):
Canonical link: https://commits.webkit.org/278624@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
