Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 252dcd59726c3971039a2b2f662b8694b31cf582
https://github.com/WebKit/WebKit/commit/252dcd59726c3971039a2b2f662b8694b31cf582
Author: Franco Vieira de Souza <[email protected]>
Date: 2026-06-10 (Wed, 10 Jun 2026)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/WebPageProxyCocoa.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SafeBrowsing.mm
Log Message:
-----------
alert() deferral logic under SafeBrowsing not properly hooked
https://bugs.webkit.org/show_bug.cgi?id=316609
rdar://179062521
Reviewed by Pascoe.
Fix latent bugs in SafeBrowsing-driven modal deferring behavior, and update
tests so that the behavior is actually exercised.
Previously, the affected tests didn't exercise the deferral path: the 50ms
SafeBrowsing delay always returned before the 250ms response-policy timeout,
so the page never committed before SafeBrowsing resolved and JS modals never
ran in the deferral window. Bumping the test delay to 1000ms forced the page
to commit before SafeBrowsing returned, surfacing bugs.
m_isSafeBrowsingCheckInProgress is now set in didCommitLoadForFrame,
based on the just-committed navigation's SafeBrowsing state. It is
cleared either when SafeBrowsing resolves clean for the currently
committed main-frame navigation, when the user resolves a warning, or
at the start of a new UIProcess-initiated navigation. Three premature
clears for the flag were removed.
Since modal IPCs are synchronous, we need to unblock the WebContent
Process with the added drainDeferredModalsForNewNavigation(), which is
called at every UIProcess-side navigation entry point.
Canonical link: https://commits.webkit.org/314891@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
