Navigation API: fix an ordering issue #11512
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Because navigatesuccess/navigateerror events can run JavaScript code, they can change the "ongoing API method tracker" pointer. Thus, it's better to resolve/reject the finished promise for the API method tracker before firing the event. This does not change the observable order in normal cases: it remains the case that JavaScript event handlers for navigatesuccess/navigateerror run before promise reactions, because promise resolution is always delayed by a microtask. However, it fixes some tricky reentrant cases.
annevk
approved these changes
Jul 31, 2025
|
This looks very reasonable. I wouldn't be surprised if we have the same bug as chromium here. |
farre
approved these changes
Aug 1, 2025
|
The test in my CL (https://chromium-review.googlesource.com/c/chromium/src/+/6622087) fails the assertion at the start of the promote an upcoming API method tracker to ongoing steps. I haven't isolated a case where a promise resolves incorrectly or anything like that yet, but we definitely are violating spec assertions. |
|
I don't have official review permissions, but the spec diffs match what I expected based on my proposed code change. |
6 tasks
noamr
added a commit
to noamr/html
that referenced
this pull request
Aug 20, 2025
noamr
added a commit
that referenced
this pull request
Aug 20, 2025
atscott
added a commit
to atscott/angular
that referenced
this pull request
Aug 25, 2025
…success] Order was changed in whatwg/html#11512 (see that PR for details as to why). https://whatpr.org/html/10919/nav-history-apis.html#abort-a-navigateevent
AndrewKushnir
pushed a commit
to angular/angular
that referenced
this pull request
Aug 27, 2025
…success] (#63377) Order was changed in whatwg/html#11512 (see that PR for details as to why). https://whatpr.org/html/10919/nav-history-apis.html#abort-a-navigateevent PR Close #63377
AndrewKushnir
pushed a commit
to angular/angular
that referenced
this pull request
Aug 27, 2025
…success] (#63377) Order was changed in whatwg/html#11512 (see that PR for details as to why). https://whatpr.org/html/10919/nav-history-apis.html#abort-a-navigateevent PR Close #63377
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Because navigatesuccess/navigateerror events can run JavaScript code, they can change the "ongoing API method tracker" pointer. Thus, it's better to resolve/reject the finished promise for the API method tracker before firing the event.
This does not change the observable order in normal cases: it remains the case that JavaScript event handlers for navigatesuccess/navigateerror run before promise reactions, because promise resolution is always delayed by a microtask. However, it fixes some tricky reentrant cases, which currently cause spec assertion failures.
This was discovered by @natechapin in https://chromium-review.googlesource.com/c/chromium/src/+/6622087, while he was implementing the fix from #11409. I'd like his review, as well as ideally @farre's.
I'm still working with Nate on getting clarity on an exact test case that exercises this bug, and what the before/after behavior is. It might be the test case already in https://chromium-review.googlesource.com/c/chromium/src/+/6622087; I'm not sure.Those tests will exercise this code path, and a spec assertion will get hit without this.(See WHATWG Working Mode: Changes for more details.)
/nav-history-apis.html ( diff )