Bug 282137
| Summary: | [Navigation] NavigationResult.finished resolves earlier than expected | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Patrick Griffis <pgriffis> |
| Component: | WebCore Misc. | Assignee: | Rob Buis <rbuis> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | rbuis, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=282475 | ||
| Bug Depends on: | |||
| Bug Blocks: | 258384 | ||
Patrick Griffis
An example of this is in the navigation-api/focus-reset/ tests, such as basic.html.
It includes the JS file navigation-api/focus-reset/resources/helpers.mjs which has code like:
const { committed, finished } = navigation.navigate("#foo");
await committed;
assert_equals(document.activeElement, button, "Focus stays on the button during the transition");
await finished.catch(() => {});
assert_equals(document.activeElement, button, "Focus stays on the button after the transition");
The issue is that the navigation blocks all the way until the point where `finished` is fulfilled.
The `committed` promise is resolved at the correct time, however the JS after it is not able to execute
until after the navigation is complete (by which point `finished` has been resolved also).
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Rob Buis
I looked a bit into this, I think this is the same problem shown by some ordering-and-transition tests, in some cases the waitForAll algorithm returns too quickly. Basically the waitForAll functionality should act like a Promise, which is currently not the case.
Rob Buis
Pull request: https://github.com/WebKit/WebKit/pull/35946
EWS
Committed 285951@main (144f09fb32d5): <https://commits.webkit.org/285951@main>
Reviewed commits have been landed. Closing PR #35946 and removing active labels.
Radar WebKit Bug Importer
<rdar://problem/138996263>