Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 240167c3110b774ae1c4c318a8b2b4ca4cb62fdc
https://github.com/WebKit/WebKit/commit/240167c3110b774ae1c4c318a8b2b4ca4cb62fdc
Author: Ahmad Saleem <[email protected]>
Date: 2026-09-23 (Wed, 23 Sep 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-child-entries-updated-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-child-entries-updated.html
A
LayoutTests/imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-sibling-detach-frame-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-sibling-detach-frame.html
M Source/WebCore/page/Navigation.cpp
Log Message:
-----------
[Navigation API] dispose events for entries truncated by another frame's
navigation see stale entries(), and detaching a frame during dispose crashes
https://bugs.webkit.org/show_bug.cgi?id=321821
rdar://184961466
Reviewed by Rupin Mittal.
When a frame performs a push navigation, the joint session history is truncated,
which must dispose the forward entries of every other frame in the tree.
Navigation::recursivelyDisposeOfForwardEntriesInParents did that in the wrong
order: it dispatched the dispose events before assigning m_currentEntryIndex and
resizing m_entries, so a dispose handler observed the entry it was being
notified
about still present in navigation.entries(), with the old currentEntry index and
a still-valid entry.index. Per spec the entry list and current entry index are
updated first and the dispose events fire afterwards, which is also what the two
sibling paths in this file already do (updateForNavigation for push/replace, and
updateForReactivation). Snapshot the doomed entries with Vector::subvector(),
truncate, then dispatch.
Dispatching those events also runs author script, which is free to detach this
frame -- for instance from the dispose handler of one of its own entries. The
child walk that follows then dereferenced a null frame() and crashed with a
segmentation fault in the WebContent process. Bail out if the frame is gone, the
same way updateNavigationEntry() already does before its identical walk.
Both new tests pass in Gecko and Chromium and failed in WebKit before this
change: the first with entries().length reporting 4 instead of 1 inside the
dispose handler, the second with a null-deref crash.
Tests:
imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-child-entries-updated.html
imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-sibling-detach-frame.html
*
LayoutTests/imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-child-entries-updated-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-child-entries-updated.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-sibling-detach-frame-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/navigation-api/per-entry-events/dispose-for-navigation-in-sibling-detach-frame.html:
Added.
* Source/WebCore/page/Navigation.cpp:
(WebCore::Navigation::recursivelyDisposeOfForwardEntriesInParents):
Canonical link: https://commits.webkit.org/321726@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
