Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: fc6c7ee22f164fda87d9c7768d1d30501a7c3348
https://github.com/WebKit/WebKit/commit/fc6c7ee22f164fda87d9c7768d1d30501a7c3348
Author: Rupin Mittal <[email protected]>
Date: 2026-06-05 (Fri, 05 Jun 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/signal-abort-replaceState-crash.html
A
LayoutTests/navigation-api/navigation-api-rate-limit-history-api-expected.txt
A LayoutTests/navigation-api/navigation-api-rate-limit-history-api.html
M LayoutTests/platform/ios/TestExpectations
M Source/WebCore/page/Navigation.cpp
Log Message:
-----------
[Navigation API] [iOS] signal-abort-window-stop-in-onnavigate.html is a flaky
timeout
https://bugs.webkit.org/show_bug.cgi?id=313562
rdar://175779061
Reviewed by Basuke Suzuki.
The test signal-abort-window-stop-in-onnavigate.html times out--but only if it's
run after signal-abort-replaceState-crash.html.
The issue is that signal-abort-replaceState-crash.html has a navigation event
listener which does a history navigation, which causes the navigation event to
fire again. There is an infinite loop of navigation + navigation event. Although
this test does seem to pass, it kicks off an infinite loop that seems to prevent
the test runner from properly resetting state between this test and the next. We
see the output:
Failed to load 'about:blank', terminating process and trying again.
...
Failed to load 'about:blank' again after termination.
and then the second test appears to begin, but never finish.
Even putting aside this test, it is problematic that the navigation event
listener
can be used to create an infinite loop of navigations. This can cause the web
process to totally consume the CPU (we do see this when running that test). This
is the very reason that the Navigation::RateLimiter exists. It caps the number
of
navigations to 200 per 10 seconds (the same limit as Chrome). But it only does
this for navigations initiated by the Navigation API. In this case, the
navigation
is initiated by the History API.
So we fix this by allowing the RateLimiter to limit non-NavigationAPI-initiated
navigations as well. This prevents the infinite loop and fixes our test.
This test has actually been changed upstream in WPT to use a Navigation API
initiated
navigation, so this test doesn't actually create an infinite loop anymore. So
we also
add a new test that checks the History API case that this test originally
contained.
*
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/signal-abort-replaceState-crash.html:
*
LayoutTests/navigation-api/navigation-api-rate-limit-history-api-expected.txt:
Added.
* LayoutTests/navigation-api/navigation-api-rate-limit-history-api.html: Added.
* LayoutTests/platform/ios/TestExpectations:
* Source/WebCore/page/Navigation.cpp:
(WebCore::Navigation::innerDispatchNavigateEvent):
Canonical link: https://commits.webkit.org/314652@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
