Navigation API: retain upcoming method tracker as temporary variable #11762
Conversation
This protects the navigation API's internal state from fudging when `navigate()` is called from within a `navigateerror` handler. Also inline "promote an upcoming API method tracker". Closes whatwg#11735
There was a problem hiding this comment.
I don't think this solves the issue. We need to retain the navigation's upcoming non-traverse API method tracker before firing the navigate error event, because that can run script, and re-apply it afterwards.
(sorry, I don't have permission to request changes)
|
|
||
| <li><p><span>Promote an upcoming API method tracker to ongoing</span> given | ||
| <var>navigation</var> and <var>destinationKey</var>.</p></li> | ||
| <li><p>Let <var>upcomingMethodTracker</var> be <var>navigation</var>'s <span>upcoming |
There was a problem hiding this comment.
nit: I don't think we need this here. It should be fine the way it was in the old version (directly move the upcoming non-traverse API method tracker into the ongoing API method tracker slot).
OK, I want to wait until #11725 is merged (cc @zcorpan) before revising this then. |
This protects the navigation API's internal state from fudging when
navigate()is called from within anavigateerrorhandler.Also inline "promote an upcoming API method tracker".
Closes #11735
navigateis called fromonnavigateerror#11735) have alerted about this.(See WHATWG Working Mode: Changes for more details.)
/nav-history-apis.html ( diff )