Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ff7c65fcd26b2075e5ad84e22326df7552dd479c
https://github.com/WebKit/WebKit/commit/ff7c65fcd26b2075e5ad84e22326df7552dd479c
Author: Sihui Liu <[email protected]>
Date: 2026-09-17 (Thu, 17 Sep 2026)
Changed paths:
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
[Site Isolation] SiteIsolation.UnresponsiveProcessMousedown fails under
shared process mode
https://bugs.webkit.org/show_bug.cgi?id=324471
rdar://187710520
Reviewed by Per Arne Vollan.
UnresponsiveProcessMousedown loads two cross-site iframes: webkit.org hangs
forever in a mousedown handler, and w3.org
busies its main thread for 3500ms in a keydown handler before recovering. The
test verifies that the page only reports
_webViewWebProcessDidBecomeResponsive: once every process is responsive again,
so the w3.org process recovering must not
clear the unresponsive state while the webkit.org process is still hung.
That only holds if the two iframes are in different processes. With shared
process mode enabled both sites land in the
same process, so the keydown reply from w3.org stops that process's single
ResponsivenessTimer while its own mousedown
is still queued behind the reply, and the page reports the process as
responsive again.
Keep w3.org out of the shared process so the test exercises what it was written
to exercise in both configurations.
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(-[NavigationDelegateWithUnresponsiveCallback
webView:decidePolicyForNavigationAction:preferences:decisionHandler:]):
(TestWebKitAPI::TEST(SiteIsolation, UnresponsiveProcessMousedown)):
Canonical link: https://commits.webkit.org/321341@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
