Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0e46277991b156ac338714ebe3dc3ad3808870f5
https://github.com/WebKit/WebKit/commit/0e46277991b156ac338714ebe3dc3ad3808870f5
Author: Rupin Mittal <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
A
LayoutTests/http/tests/security/mixedContent/mainframe-onload-after-iframe-block.https-expected.txt
A
LayoutTests/http/tests/security/mixedContent/mainframe-onload-after-iframe-block.https.html
M Source/WebCore/loader/FrameLoader.cpp
Log Message:
-----------
[Site Isolation] Main frame onload event does not fire if iframe load is
blocked
https://bugs.webkit.org/show_bug.cgi?id=312358
rdar://161348735
Reviewed by Charlie Wolfe.
Once child frames have finished loading (or failed to load), the main frame's
onload event must fire. But with site isolation on, when the iframe load is
blocked by the mixed content checker, the main frame's onload event never fires.
With site isolation off, the way this works is:
1. Main frame begins loading but is blocked from completing by the iframe's
load.
2. DocumentLoader::startLoadingMainResource() starts loading the iframe
3. MixedContentChecker::shouldBlockRequest() returns that we should block
4. DocumentLoader::cancelMainResourceLoad()
5. FrameLoader::checkCompleted() sets m_isComplete on the iframe and calls
6. FrameLoader::checkCompleted() on the parent frame (the main frame)
7. Document::implicitClose()
8. Document::dispatchWindowLoadEvent()
9. LocalDOMWindow::dispatchLoadEvent()
With site isolation on, when FrameLoader::checkCompleted() is called on the
iframe,
we don't go any further because the m_isComplete flag is already set to true.
This
is because this iframe's flag was never set to false by FrameLoader::started()
when the load began because this function isn't called on the LocalFrame iframe
that is created for loads that occur in another process. So we never call
FrameLoader::checkCompleted() on the main frame to tell it the load finished.
Since the load finished in another process, this process needs to send a message
to the main frame's web process and tell it the load finished. This already
happens.
When the iframe's load gets blocked, the web process notifies the UI Process of
this,
and it calls FrameLoader::provisionalLoadFailedInAnotherProcess() on the loader
associated with the same frame in the main frame's process. The issue is that
this
function does not call checkCompleted() on the main frame so that it may fire
its
onload event.
To fix this, we amend FrameLoader::provisionalLoadFailedInAnotherProcess() to
call
FrameLoader::checkCompleted() on the parent (main) frame. This function will
check
that all children are complete. So we must also set m_isComplete to true for
this
iframe before calling checkCompleted() on the parent.
This is covered by a new layout test that passes with both site isolation on
and off.
*
LayoutTests/http/tests/security/mixedContent/mainframe-onload-after-iframe-block.https-expected.txt:
Added.
*
LayoutTests/http/tests/security/mixedContent/mainframe-onload-after-iframe-block.https.html:
Added.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::provisionalLoadFailedInAnotherProcess):
Canonical link: https://commits.webkit.org/311314@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
