Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b6915afa938b99e8b6a2ec82d863aa6c8410a73c
https://github.com/WebKit/WebKit/commit/b6915afa938b99e8b6a2ec82d863aa6c8410a73c
Author: Rupin Mittal <[email protected]>
Date: 2025-10-06 (Mon, 06 Oct 2025)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigation-methods/disambigaute-forward-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigation-methods/disambigaute-traverseTo-forward-multiple-expected.txt
M Source/WebCore/loader/HistoryController.cpp
Log Message:
-----------
[Navigation API] navigate.back doesn't work in main frame when preceded by
navigate.back in child frame (part 2)
https://bugs.webkit.org/show_bug.cgi?id=297365
rdar://158259024
Reviewed by Basuke Suzuki.
The test disambigaute-forward.html fails on this line:
"assert_equals(navigation.currentEntry.index, start_index);"
because the mainframe's back navigation fails.
This is what the test is doing:
1. Load a main frame and an iframe
2. Fragment navigate the main frame
3. Fragment navigate the iframe
4. Go back in the iframe (this succeeds)
5. Go back in the main frame (this fails to go back)
The main frame's m_entries correctly looks like:
MainFrame (URL: disambigaute-forward.html, itemID: A)
MainFrame (URL: disambigaute-forward.html#top, itemID: B)
But on the navigate.back, the item we're looking for is wrong. We're looking
for item B when we should have been looking for item A.
Why? On navigate.back, for most of the code path, we are correctly using item A.
But then:
FrameLoader::loadInSameDocument() ends up calling
HistoryController::recursiveUpdateForSameDocumentNavigation() which sets the
currentItem to the provisionalItem. The currentItem is the item we're looking
for.
Up to this point, it has correctly been item A. But here, we set it to item B.
Turns out, the provisionalItem got set to item B by the iframe's back navigation
in HistoryController::recursiveSetProvisionalItem(). In the iframe's back, we
actually call recursiveSetProvisionalItem from the main frame's history
controller.
This means that we set the provisional item for the main frame--even though the
main frame is not actually navigating. Since the main frame isn't navigating,
this
provisional item does not get set to nullptr when the iframe's load finishes. So
later on, this causes the main frame's back to look for the wrong item and for
the
back to fail.
On the iframe's back, this provisional item should have been cleared by
recursiveUpdateForSameDocumentNavigation. (If it was cleared, then on the main
frame's back, the currentItem would be correct and the back navigation would
succeed). But it doesn't get cleared because shouldDoSameDocumentNavigationTo is
false. The current item and provisional item for the main frame are both item B.
This is because the main frame's history controller's current item does not
change
when the iframe navigates forward.
So this check is cutting off the correct recursive update of frames and later
preventing the main frame from navigating correctly.
This check was first added in https://commits.webkit.org/84130@main. The tests
added in that patch are still present in the codebase and pass even when this
check
is removed. So we can safely remove it.
*
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigation-methods/disambigaute-forward-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigation-methods/disambigaute-traverseTo-forward-multiple-expected.txt:
* Source/WebCore/loader/HistoryController.cpp:
(WebCore::HistoryController::recursiveUpdateForSameDocumentNavigation):
Canonical link: https://commits.webkit.org/301092@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
