Navigation API: Move resolving/rejecting ongoing API method tracker to before running script.

[jnjaeschke]

This fixes #12617.

This fixes an issue where script could run mid-cleanup of an existing navigation (navigate event was already cleared, but ongoing API method tracker was not), which could then trigger an assert if a new navigation was started.

• [] At least two implementers are interested (and none opposed):
  • Mozilla
  • …
• Tests are written and can be reviewed and commented upon at:
  • https://phabricator.services.mozilla.com/D308765
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2046994
  • WebKit: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/nav-history-apis.html ( diff )

[annevk]

Any reason this doesn't use the complete PR template? It's a normative change for a feature that shipped everywhere so it probably should.

[jnjaeschke]

Apologies. I skipped the template because it's such a small change (and most/all parts of the template don't apply). I updated the initial comment.

[noamr]

The change looks good.
How come most parts of the template don't apply?
https://phabricator.services.mozilla.com/D308765 seems like a gecko link rather than a test link?
Does this mean that current test capture this and WebKit/Blink does the right thing?