Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 149feb1b99dbf9c1d49957cef6d69fc20bc3a4c6
https://github.com/WebKit/WebKit/commit/149feb1b99dbf9c1d49957cef6d69fc20bc3a4c6
Author: Ryosuke Niwa <[email protected]>
Date: 2026-09-21 (Mon, 21 Sep 2026)
Changed paths:
A
LayoutTests/http/tests/site-isolation/post-message-in-subframe-load-event-expected.txt
A
LayoutTests/http/tests/site-isolation/post-message-in-subframe-load-event.html
A
LayoutTests/http/tests/site-isolation/resources/post-message-to-parent-in-load-event.html
M LayoutTests/platform/ios-site-isolation/TestExpectations
M Source/WebCore/page/LocalDOMWindow.cpp
M Source/WebCore/page/LocalFrame.cpp
M Source/WebCore/page/LocalFrame.h
Log Message:
-----------
[Site Isolation]
imported/w3c/web-platform-tests/fetch/api/redirect/redirect-keepalive.https.any.html
is a flaky timeout
https://bugs.webkit.org/show_bug.cgi?id=324741
Reviewed by Basuke Suzuki.
keepalive-helper.js adds its message event listener only after awaiting the
load event of the
iframe it creates, and keepalive-redirect-iframe.html posts the token back from
that subframe's
own load event handler. When the message arrives first nothing is listening for
it,
getTokenFromMessage() never resolves, and the promise_test times out.
When both frames are in the same process the owner element's load event always
comes first:
postMessage queues a task on the parent's event loop, and
LocalDOMWindow::dispatchLoadEvent then
dispatches the owner element's load event synchronously on the same stack.
With site isolation the subframe instead sends two messages, in this order:
WebPageProxy::PostMessageToRemote from its load event handler, and
WebPageProxy::DispatchLoadEventToFrameOwnerElement once those handlers return.
Both reach the
parent's process in order over the same connection, but
WebPage::remotePostMessage queues an
event loop task while WebPage::dispatchLoadEventToFrameOwnerElement dispatches
the load event
synchronously. WindowEventLoop::scheduleToRun uses a zero delay timer, so
whenever that timer
fires before the second message is dispatched the parent observes the message
first. Loading such
a subframe 30 times reversed the order 5 times.
Notify the owner element in the other process before running this frame's own
load event
handlers, so a message one of them posts cannot be sent ahead of it. Ordering
on the connection
then delivers the load event to the parent first, as it is in the same process
case.
Nothing changes without site isolation: the parent is never a RemoteFrame
there, so
dispatchLoadEventToRemoteParent() returns false without side effects and
dispatchLoadEventToParent()
runs where it did before.
Test: http/tests/site-isolation/post-message-in-subframe-load-event.html
*
LayoutTests/http/tests/site-isolation/post-message-in-subframe-load-event-expected.txt:
Added.
*
LayoutTests/http/tests/site-isolation/post-message-in-subframe-load-event.html:
Added.
*
LayoutTests/http/tests/site-isolation/resources/post-message-to-parent-in-load-event.html:
Added.
* LayoutTests/platform/ios-site-isolation/TestExpectations:
* Source/WebCore/page/LocalDOMWindow.cpp:
(WebCore::LocalDOMWindow::dispatchLoadEvent):
* Source/WebCore/page/LocalFrame.cpp:
(WebCore::LocalFrame::dispatchLoadEventToRemoteParent):
(WebCore::LocalFrame::dispatchLoadEventToParent):
* Source/WebCore/page/LocalFrame.h:
Canonical link: https://commits.webkit.org/321568@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
