Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 799571146940807a81c8ad8a8d5159a1f6b22009
https://github.com/WebKit/WebKit/commit/799571146940807a81c8ad8a8d5159a1f6b22009
Author: Anne van Kesteren <[email protected]>
Date: 2026-09-02 (Wed, 02 Sep 2026)
Changed paths:
A
LayoutTests/http/wpt/html/browsers/windows/resources/post-search-to-broadcast-channel.html
A
LayoutTests/http/wpt/html/browsers/windows/target-blank-not-cancelled-by-fragment-navigation-expected.txt
A
LayoutTests/http/wpt/html/browsers/windows/target-blank-not-cancelled-by-fragment-navigation.html
M Source/WebKit/UIProcess/WebFrameProxy.cpp
M Source/WebKit/UIProcess/WebFrameProxy.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp
M Source/WebKit/WebProcess/WebPage/WebFrame.cpp
M Source/WebKit/WebProcess/WebPage/WebFrame.h
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/OpenAndCloseWindow.mm
Log Message:
-----------
A policy check that does not navigate a frame is cancelled by one that does
https://bugs.webkit.org/show_bug.cgi?id=37756
rdar://186253237
Reviewed by Alex Christensen.
A target=_blank activation navigates the new frame it creates, not the
frame the link was activated in. The policy check for it is made in that
source frame all the same, and WebKit routed it through machinery that
assumes any check a frame makes is for a load of its own, in both
processes, so anything the source frame did next destroyed it.
In the UI process WebFrameProxy keeps one policy listener per frame and
setUpPolicyListenerProxy() resolves the previous one with ignore(), so
each activation cancelled the one before it: N target=_blank clicks in a
single task opened one window, the last. In the web process
PolicyChecker::stopCheck() answers every outstanding check with
PolicyAction::Ignore, so a navigation of the source frame in the same
task lost the window outright.
319105@main took download attribute checks out of these same two
cancellations, though that case is not quite this one: activating a
download attribute link is still a navigation of a kind, and one the
client can answer Use for, which makes it an ordinary one. What it shares
with creating a new frame is that when the check is made no load in this
frame is waiting on the answer, so nothing the frame does next
invalidates it - unlike the check for a redirect in the load an allowed
activation starts, whose DocumentLoader is. Both now turn on that rather
than on what kind of check it is.
The single listener in the UI process dates to 193833@main. 240828@main
made the web process able to hold several checks at once for this exact
symptom, citing WPT tests that timed out because "only the last one would
proceed", but left the UI process alone, so the symptom survived wherever
the embedder does not answer policy synchronously. It still shows in
Safari:
imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/target_blank_implicit_noopener.html
passes under WebKitTestRunner and reports 1 of 13 subtests in Safari,
always the last.
The API test holds every new window decision instead of answering it, so
all five checks are outstanding at once. As 319105@main notes, a delegate
that answers immediately never reaches that state, so no layout test can
cover the UI process half; one that answers after a single run loop hop
reaches it only as a race, which made the layout test written first pass
4 times in 10. The web process half needs no held decision - the check is
outstanding across the reply from the UI process however fast it comes -
so a layout test covers that one.
Canonical link: https://commits.webkit.org/320325@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
