Clarify how to cancel a navigation

[zcorpan]

@rwaldron and I reasoned a bit around these tests web-platform-tests/wpt#8558 and found a possible problem with how HTML cancels navigation attempts. It won't remove any "navigate" tasks that still exist on the task queue. Is that intentional?

Consider this test

https://github.com/w3c/web-platform-tests/pull/8558/files#diff-cc01cb4065c5670fb1bf4b19c88fd562

click() will do

https://html.spec.whatwg.org/#the-a-element:following-hyperlinks-2-2
and step 14 in
https://html.spec.whatwg.org/#following-hyperlinks-2

Queue a task to navigate the target browsing context to resource. If replace is true, the navigation must be performed with replacement enabled. The source browsing context must be source.

Note "queue a task".

Then the test also has

onclick="document.querySelector('iframe').src='javascript:`<script>parent.verifyNavigation(false);</script>`';"

https://html.spec.whatwg.org/#the-iframe-element:attr-iframe-src-4
https://html.spec.whatwg.org/#otherwise-steps-for-iframe-or-frame-elements
which step 4 says to navigate, without queueing a task:

Navigate the element's nested browsing context to resource.

So the iframe src navigation starts first (and it will queue another task for https://html.spec.whatwg.org/#javascript-protocol ). Then the hyperlink navigation starts, which cancels the src navigation.

If the above analysis is correct and the behavior is intentional, we should probably clarify in the spec that canceling navigations does not mean to remove tasks from the task queue. OTOH, if removing tasks is a thing browsers do, we should specify that. Maybe each browsing context can have an internal slot to track the most recent navigation to cancel, and have an abstract operation that handles queued task case as well as started case.

---

Places where the spec cancels navigations:

https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate

step 6:

Cancel any preexisting but not yet mature attempt to navigate browsingContext, including canceling any instances of the fetch algorithm started by those attempts. If one of those attempts has already created and initialized a new Document object, abort that Document also. (Navigation attempts that have matured already have session history entries, and are therefore handled during the update the session history with the new page algorithm, later.)

https://html.spec.whatwg.org/#traverse-the-history-by-a-delta

step 5.1:

If there is an ongoing attempt to navigate specified browsing context that has not yet matured (i.e. it has not passed the point of making its Document the active document), then cancel that attempt to navigate the browsing context.

[TimothyGu]

Another place where navigation is canceled:

https://html.spec.whatwg.org/multipage/window-object.html#dom-window-stop

The stop() method on Window objects should, if there is an existing attempt to navigate the browsing context and that attempt is not currently running the unload a document algorithm, cancel that navigation; ...

(And soon that algorithm will be called in document.open() through #3999 also.)

[bzbarsky]

See also #3730

I was recently looking at this area of code in Firefox, and it looks like Firefox queues a task to navigate from "follow a hyperlink" but not from form submission or location href sets. #3730 suggests that some browsers do it for location href sets too. In any case, there's an interop problem here. This testcase:

<a href="http://example.com"></a>
<script>
  document.querySelector("a").click();
  location.href = "http://software.hixie.ch/utilities/cgi/test-tools/delayed-file?pause=2&mime=text%2Fplain&text=Testing.";
</script>

ends up loading example.com in Firefox but the software.hixie.ch page in Chrome and Safari. Per spec as written it should load the example.com page, but that seems pretty weird to me.

My preference for this stuff in a vacuum would be that neither following a hyperlink nor location sets queue a task. A task would still be queued for javascript: execution under navigation. But I'd really like to know what exactly Chrome and Safari do here.

@domenic do you know what Chrome does or who would know?

@rniwa same thing for Safari: do you know what the actual behavior is or who would know?

@annevk

[domenic]

Based on #3730 I'm going to guess that @zetafunction is the right person on Chrome to describe our navigation/task-queuing behavior. Indeed, this is quite an interop mess.

[fergald]

Does anyone have a non-racy example of a use case for stopping navigations on document.open? By racy I mean, e.g. if the navigation is triggered in a JS task and the open is called in a subsequent task, then this is racy as it depends on the navigation taking some amount of time - if it's quick enough we don't make it to the open. It seems that to reliably depend on this feature you would have to request the navigation and then later in the same task call open and I'm curious if this is something that is actually done in reality. Would it be OK to spec this as requesting cancellation of ongoing navigation without guaranteeing it so that all uses of this are equally racy? Pages that really need to end their tasks with if (we_didnt_call_open) {do_that_navigation()} Maybe not a very attractive proposition...

The reason I ask is that this is looking like the only place where the page gets synchronous control over cross-document navigation (if you know of others, please tell me) and we might end up implementing that if under the hood.

[domenic]

I suspect a common pattern that isn't racy in current browsers is

location.href = "foo";
// ...later in the same task...
document.open();

[domenic]

The reason I ask is that this is looking like the only place where the page gets synchronous control over cross-document navigation (if you know of others, please tell me)

I think window.stop() is also specced to synchronously cancel cross-document navigations, currently.