Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: d4b8cb8d2eef6760b8c4e09aee8105ce788a17cd
https://github.com/WebKit/WebKit/commit/d4b8cb8d2eef6760b8c4e09aee8105ce788a17cd
Author: Sihui Liu <[email protected]>
Date: 2026-09-10 (Thu, 10 Sep 2026)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] A dialog from a document the page has left can still reach
the client
https://bugs.webkit.org/show_bug.cgi?id=323687
rdar://186946399
Reviewed by Brady Eidson.
SiteIsolation.QueuedDialogPurgedByMainFrameNavigation fails with
SiteIsolationSharedProcessEnabled. When two iframes end
up in the same process, the modal run loop for the first frame's alert() blocks
the second frame's script, so its
request only reaches the UI process after the first dialog is dismissed.
purgeQueuedModalDialogs() has long since run -
it fires when the main frame starts a provisional load - so the late request is
queued and shown, on behalf of a page
the user has already left. This is not specific to shared process mode: two
same-site iframes share a process in the
default configuration and reproduce it, which is what the new test
QueuedSameProcessDialogPurgedByMainFrameNavigation
covers.
Check in WebPageProxy::runModalJavaScriptDialog, the single funnel for alert,
confirm and prompt, that the requesting
frame is still in the displayed frame tree, and cancel it if not.
DialogDisposition::Cancel is the path the purge
already uses: it replies to the Web process so the blocked alert() returns,
without invoking the UI client. The check
runs again on the way out of the queue, since the tree can change while a
request waits there.
This is a frame-identity check, so it is not the complete fix. It cannot
separate two documents that share one
WebFrameProxy - ProvisionalPageProxy's m_shouldReuseMainFrame branch - and for
a same-process main frame navigation it
only takes effect once didDestroyFrame has arrived, so it depends on that
teardown IPC rather than on the commit. The
complete fix is document identity: compare the requesting document's identifier
against the one committed in that frame,
and that frame's top document against the main frame's. It is blocked on a
separate defect - on a back/forward cache
restore didCommitLoadForFrame reports the identifier of the document being
navigated away from, because
FrameLoader::commitProvisionalLoad dispatches the commit before it restores the
cached page - and will be followed up
separately.
Verified that a back/forward cache restore is not over-refused: after going
back, dialogs from the restored main frame
and from its restored cross-site subframe are still delivered.
Tests: SiteIsolation.QueuedSameProcessDialogPurgedByMainFrameNavigation
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::isInDisplayedFrameTree):
(WebKit::WebPageProxy::runModalJavaScriptDialog):
(WebKit::WebPageProxy::runNextModalJavaScriptDialogIfNeeded):
(WebKit::WebPageProxy::purgeQueuedModalDialogs):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::TEST(SiteIsolation, QueuedDialogPurgedByMainFrameNavigation)):
(TestWebKitAPI::TEST(SiteIsolation,
QueuedSameProcessDialogPurgedByMainFrameNavigation)):
Canonical link: https://commits.webkit.org/320870@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
