Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: c6f4d9a1c0615dffc995046a164de231cc40756f
https://github.com/WebKit/WebKit/commit/c6f4d9a1c0615dffc995046a164de231cc40756f
Author: Rupin Mittal <[email protected]>
Date: 2025-08-15 (Fri, 15 Aug 2025)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/Download.mm
M Tools/TestWebKitAPI/Tests/mac/LoadWebArchive.mm
Log Message:
-----------
Navigation isRequestFromClientOrUserInput is incorrectly true for window.open
call with web archive
https://bugs.webkit.org/show_bug.cgi?id=295655
rdar://154084804
Reviewed by Youenn Fablet.
When a web archive is navigated to from a `window.open` call, it's not
client or user initiated--it's programmatically initiated from JavaScript.
But currently, the navigation is incorrectly being marked as client or
user initiated.
So when the request loads, and DocumentLoader checks if it's allowed to
load the web archive:
bool allowsWebArchiveForMainFrame() const { return
m_isRequestFromClientOrUserInput; }
it assumes that it can, and it wrongly loads. We can verify that this
happens in MiniBrowser.
The issue is that WebPageProxy::loadRequest() always marks the navigation
as client or user initiated. Now this is fine in cases where the call to
WebPageProxy::loadRequest() comes from the client via the client making
an API call to WKWebView::loadRequest. But in this case, the client isn't
making an API call. Rather, WebPageProxy::loadRequest() is being called
by WebKit internally. `window.open` leads to WebPageProxy::createNewPage(),
which leads to WebPageProxy::loadRequest().
In this case, we want to tell WebPageProxy::loadRequest() that this is
not client or user initiated. This information is contained in the
`NavigationActionData navigationDataForNewProcess`. So we pass this on
from WebPageProxy::createNewPage() to WebPageProxy::loadRequest().
In all other cases, we keep the current behavior of the navigation being
marked as client or user initiated.
This is tested by a new API test.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::loadRequest):
This will mark the navigation as client or user initiated based on the
new flag being passed in (isRequestFromClientOrUserInput). To ensure
existing behavior doesn't change for other cases, this is true by default.
(WebKit::WebPageProxy::createNewPage):
Since WebKit is internally calling loadRequest from here, we explicitly
pass in navigationDataForNewProcess->isRequestFromClientOrUserInput.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/Download.mm:
(TestWebKitAPI::OriginatingFrameWhenConvertingNavigationInNewWindow)):
The first navigation in this test comes from "a.href" (programmatically
initiated by Javascript). On this call, WebKit is internally calling
WebPageProxy::loadRequest. Before this patch here, this was being marked
as client or user input.
In the fix for https://bugs.webkit.org/show_bug.cgi?id=293994, we changed
WebPageProxy::receivedNavigationResponsePolicyDecision such that if the
navigation was from a client or user input, then the information about the
originating frame would be set to empty. At that time, this first navigation
was going down that code path, so we had to alter the test accordingly.
Now, with this patch, that navigation is correctly being marked as NOT
client or user input. So it's no longer going down the code path introduced
in that previous patch, and we can now remove those changes to the test.
* Tools/TestWebKitAPI/Tests/mac/LoadWebArchive.mm:
(TestWebKitAPI::TEST(LoadWebArchive,
FailNavigationFromNonClientOrUserInitiatedWindowOpen)):
New API test.
Originally-landed-as: 289651.603@safari-7621-branch (52189fdc734f).
rdar://157788008
Canonical link: https://commits.webkit.org/298780@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
