Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 1632df729caed9bbd3e75fe1332f6d2464f49781
https://github.com/WebKit/WebKit/commit/1632df729caed9bbd3e75fe1332f6d2464f49781
Author: Rupin Mittal <[email protected]>
Date: 2026-06-10 (Wed, 10 Jun 2026)
Changed paths:
M Source/WebKit/UIProcess/WebFrameProxy.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WebLocks.mm
Log Message:
-----------
StabilityTracer: MobileSafari at Received an invalid message
'WebLockRegistryProxy_ClientIsGoingAway'
https://bugs.webkit.org/show_bug.cgi?id=315738
rdar://178065152
Reviewed by Charlie Wolfe.
The message check added to requestLock() and clientIsGoingAway():
MESSAGE_CHECK(m_process->hasCommittedClientOrigin(clientOrigin));
may still fail after the fix in rdar://177020691.
The issue is that the ClientOrigins that the UI process stores in the map
may be different than the ones sent by web process to requestLock().
The ClientOrigins that the web process sends are computed in
WebLockManager::clientOriginFromContext(). In cases where the document's
topOrigin or securityOrigin is inherited from the parent or owner document,
this function will indeed use the inherited origins.
But the UI process side doesn't account for inherited security origins.
WebFrameProxy::didCommitLoad() computes the topOrigin and securityOrigin
straight from the URL. So in the case of an about:blank URL, it will
compute an opaque securityOrigin, whereas the web process will find and
send over the inherited securityOrigin.
The new test WebLocks.CrossSiteIframeUsingLocksInsideAboutBlankPopup
demonstrates such a scenario. In this case, there is a main frame hosted
on server1. It creates an about:blank popup and embeds in it an iframe that
is hosted on server2.
The UI process will store the following (topOrigin, securityOrigin):
main frame: { server1, server1 }
popup: { opaque1, opaque2 }
iframe: { opaque3, server2 }
The web process accounts for inherited origins and will have:
main frame: { server1, server1 }
popup: { server1, server1 }
iframe: { server1, server2 }
So when the iframe sends the requestLock() or clientIsGoingAway() IPCs,
its ClientOrigin isn't found in the map, and the message check kills the
web process.
We need to replicate the inheritance logic of the web process in the UI process.
This already exists in WebFrameProxy::updateDocumentSecurityOrigin(). So we fix
the issue by ensuring that we pass the creator (parent or opener if there's no
parent) to this function so that it correctly computes and sets the
documentSecurityOrigin and then using these computed securityOrigins.
* Source/WebKit/UIProcess/WebFrameProxy.cpp:
(WebKit::WebFrameProxy::didCommitLoad):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WebLocks.mm:
(TestWebKitAPI::TEST(WebLocks, CrossSiteIframeUsingLocksInsideAboutBlankPopup)):
Canonical link: https://commits.webkit.org/314987@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
