Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 607d216d17bb7419ef491c1d09f341c75f5f7c76
https://github.com/WebKit/WebKit/commit/607d216d17bb7419ef491c1d09f341c75f5f7c76
Author: Alex Christensen <[email protected]>
Date: 2026-07-10 (Fri, 10 Jul 2026)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Add another early return in
WebPageProxy::didSameDocumentNavigationForFrameViaJS
https://bugs.webkit.org/show_bug.cgi?id=319029
rdar://180738945
Reviewed by Abrar Rahman Protyasha.
This is similar to 287896@main.
When an iframe navigates from one site to another with site isolation enabled,
there is a time between when the UI process sends
WebPage::LoadDidCommitInAnotherProcess
and when the navigated-from web content process receives it and stops JS
execution.
During this time, JS can set window.location.hash to something, which sends
WebPageProxy::DidSameDocumentNavigationForFrameViaJS to the UI process from the
navigated-from web content process. Ever since 313796@main that triggers a
MESSAGE_CHECK in the UI process because the UI process's notion of which site
is being shown in the frame and the navigated-from web content process's site
are not the same. When this race condition is hit, we can safely ignore the
message from the old web content process.
The race condition is so rare that attempts at making unit tests to hit it
have been unfruitful. WebCore::Navigation::RateLimiter makes it so we can
only attempt 200 navigations per 10 second window, which is not enough to
hit the MESSAGE_CHECK reasonably.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didSameDocumentNavigationForFrameViaJS):
Canonical link: https://commits.webkit.org/316899@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
