Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: c0ca2b2a9f47c653d83beaf6f54213ee73b6f0b0
https://github.com/WebKit/WebKit/commit/c0ca2b2a9f47c653d83beaf6f54213ee73b6f0b0
Author: Rupin Mittal <ru...@apple.com>
Date: 2025-09-11 (Thu, 11 Sep 2025)
Changed paths:
M Source/WebCore/history/BackForwardController.cpp
M Source/WebCore/history/BackForwardController.h
M Source/WebCore/page/Navigation.cpp
Log Message:
-----------
[Navigation API] Fix 16% PLT regression by removing Sync IPC
https://bugs.webkit.org/show_bug.cgi?id=298498
rdar://160000632
Reviewed by Charlie Wolfe.
When a new Document is created, its Navigation object's list of history entries
must be initialized. In the initial implementation of the Navigation API in
273532@main, this was done by making a sync IPC to the UI Process to get each
item in the b/f list. (The calls to itemAtIndex()). 298922@main changed this so
the whole list is retrieved in just one sync IPC call (The call to
itemsForFrame()).
Then, the list would be filtered to keep only the items that this frame could
reach
via the Navigation API.
So enabling the Navigation API means that every time a new Document is created,
a new sync IPC is sent. This is terrible for performance. It's a ~16% PLT
regression.
To fix this, this patch removes this extra sync IPC. Instead of getting this
list
via IPC, we get the list from the previous Document.
There are three situations to handle:
1. If the previous Document is of the same origin, then it will have list we
need.
It will not have the new entry that triggered this navigation, but we can
add this.
Since the previous list only contains items reachable via the Navigation
API, we
do not need to filter out any items.
2. If the previous Document is not of the same origin, it means we don't need
the
entries of it's list. The only entry in the new Document's list should be the
entry that triggered this navigation. So we can initialize the new list with
just
this entry.
These two situations are handled.
3. If we are creating this Document as a result of a back/forward navigation
that is
cross-origin, then the previous Document's entries are not needed. But we
must
restore the entries that this Document used to have. For example, imagine we
do
the following navigations in the same frame:
google.com
google.com#1
google.com#2
webkit.org
go back
Then navigation.entries() should contain three entries:
(google.com, google.com#1, google.com#2).
Currently, it will (wrongly) contain only the last. This wrong behavior
predates
this patch. Since this patch simply aims to remove the sync IPC, it does not
fix
this behavior. A bug has been filed:
https://bugs.webkit.org/show_bug.cgi?id=298683.
* Source/WebCore/history/BackForwardController.cpp:
(WebCore::BackForwardController::itemsForFrame): Deleted.
* Source/WebCore/history/BackForwardController.h:
* Source/WebCore/page/Navigation.cpp:
(WebCore::getEntryIndexOfHistoryItem):
(WebCore::Navigation::initializeForNewWindow):
- Get the previous Document's list regardless of if the previous Document was
in the
main frame or a subframe.
- No need for the filtering since we aren't getting the entire unfiltered b/f
list from
the UI Process but rather the previous Document's already filtered list.
- Add the entry that triggered this navigation.
(WebCore::Navigation::updateForReactivation):
This patch initially causes the https-in-page-cache.html test to fail. That's
because
in this situation, the second location change is a
RedirectWithLockedBackForwardList
with the history handling set to Push. The UI Process does a replace but the
Navigation API spec expects a Push operation--a second item to be added to b/f
list
(https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-location-interface:location-object-navigate).
Now that we are getting the list from the previous window instead of the UI
Process,
we end up two items with the same itemID in updateForReactivation. So instead of
comparing with the itemID, we must compare with itemSequenceNumber.
Canonical link: https://commits.webkit.org/299858@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
