Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 5b7a109714d5188324cdcae0f615c64708b73f29
https://github.com/WebKit/WebKit/commit/5b7a109714d5188324cdcae0f615c64708b73f29
Author: Sihui Liu <[email protected]>
Date: 2026-10-09 (Fri, 09 Oct 2026)
Changed paths:
M Source/WebKit/UIProcess/Inspector/WebPageInspectorController.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/ProcessSwapOnNavigation.mm
Log Message:
-----------
Web Inspector: Going back to a page restored from the back/forward cache
after process swap reports "domain already enabled" errors
https://bugs.webkit.org/show_bug.cgi?id=326634
rdar://189375630
Reviewed by Qianlang Chen.
When a cross-site navigation swaps processes, didCommitProvisionalPage()
removes the targets of the old page but only
tells the frontend they were destroyed. It never disconnects them, so if the
old page is suspended into the back/forward
cache, its PageInspectorTarget in the WebContent process keeps its frontend
channel and all of its agents stay enabled.
Going back restores that suspended page with the same WebPageID, so the
provisional page target gets the same identifier
as before. PageInspectorTarget::connect() returns early because the old channel
still exists. The frontend treats the
target as new and sends its usual enable commands (Page.enable,
Debugger.enable, Heap.enable, ...), and the backend
rejects each one with "... domain already enabled".
In engineering builds, UncaughtExceptionReporter catches these unhandled
promise rejections and replaces Web Inspector
with "Web Inspector encountered an internal error". Production builds strip the
Debug/ resources, so the rejections are
only logged to the frontend's own console. Some commands sent to the restored
target can also go unanswered.
Fix this by disconnecting each removed target before reporting it destroyed
when a frontend is connected. The old page
target is disconnected by sending DisconnectInspector to the old process
directly, because PageInspectorTargetProxy
routes messages through the WebPageProxy, which already points at the new
process at this point. Frame targets know
their own process and frame, so they use disconnect().
Test: ProcessSwap.WebInspectorReconnectsPageRestoredFromBackForwardCache
* Source/WebKit/UIProcess/Inspector/WebPageInspectorController.cpp:
(WebKit::WebPageInspectorController::didCommitProvisionalPage):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/ProcessSwapOnNavigation.mm:
((ProcessSwap, WebInspectorReconnectsPageRestoredFromBackForwardCache)):
Canonical link: https://commits.webkit.org/323239@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
