What is the issue with the HTML Standard?
Case 1:
#navigate-event-intercept-commit-handler-steps first clears the ongoing navigate event, then calls #navigateevent-finish, and then resolves the finished promise for the ongoing API method tracker (which nulls the ongoing API method tracker).
#navigateevent-finish can run script, and therefore initiate a new navigation before the ongoing API method tracker is reset to null. Then, #inner-navigate-event-firing hits the assert that the ongoing API method tracker must be null.
Case 2
#abort-a-navigateevent nulls the navigate event, then signals abort, then rejects the finished promise of the ongoing API method tracker. #run-the-abort-steps fires the abort event, in which authors could initiate a new navigation, triggering the same condition as case 1.
I believe this can easily be fixed by moving the resolve/reject of the finished promise before running script. Tests look green in my Gecko implementation, and I'll create a spec PR shortly.
cc @farre @noamr @zcorpan
What is the issue with the HTML Standard?
Case 1:
#navigate-event-intercept-commit-handler-steps first clears the ongoing navigate event, then calls #navigateevent-finish, and then resolves the finished promise for the ongoing API method tracker (which nulls the ongoing API method tracker).
#navigateevent-finishcan run script, and therefore initiate a new navigation before the ongoing API method tracker is reset to null. Then,#inner-navigate-event-firinghits the assert that the ongoing API method tracker must be null.Case 2
#abort-a-navigateevent nulls the navigate event, then signals abort, then rejects the finished promise of the ongoing API method tracker. #run-the-abort-steps fires the abort event, in which authors could initiate a new navigation, triggering the same condition as case 1.
I believe this can easily be fixed by moving the resolve/reject of the finished promise before running script. Tests look green in my Gecko implementation, and I'll create a spec PR shortly.
cc @farre @noamr @zcorpan