16801 – It's unclear here and elsewhere what it means to "cancel the navigation", and what effects it will have e.g. on the parser (presumably it will be like getting EOF?). Could this be clarified, perhaps by rewriting in terms of the abort algorithm?

This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16801 - It's unclear here and elsewhere what it means to "cancel the navigation", and what effects it will have e.g. on the parser (presumably it will be like getting EOF?). Could this be clarified, perhaps by rewriting in terms of the abort algorithm?

Summary: It's unclear here and elsewhere what it means to "cancel the navigation", and...

Status:	RESOLVED FIXED

Alias:	None

Product:	WHATWG
Classification:	Unclassified
Component:	HTML (show other bugs)
Version:	unspecified
Hardware:	Other other

Importance:	P3 normal
Target Milestone:	Unsorted
Assignee:	Ian 'Hixie' Hickson
QA Contact:	contributor

URL:	http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:

Duplicates (1):	16800 (view as bug list)
Depends on:
Blocks:

Reported:	2012-04-19 16:04 UTC by contributor
Modified:	2012-12-01 00:46 UTC (History)
CC List:	4 users (show)

See Also:

Attachments

Description contributor 2012-04-19 16:04:59 UTC

Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#dom-window-stop
Complete: http://www.whatwg.org/c#dom-window-stop

Comment:
It's unclear here and elsewhere what it means to "cancel the navigation", and
what effects it will have e.g. on the parser (presumably it will be like
getting EOF?). Could this be clarified, perhaps by rewriting in terms of the
abort algorithm?

Posted from: 2001:4c28:a030:30:219:99ff:fe0e:5501
User agent: Opera/9.80 (X11; Linux x86_64; U; Edition Next; en) Presto/2.10.282 Version/12.00

Comment 1 Henri Sivonen 2012-04-23 06:42:30 UTC

window.stop() in WebKit and Gecko and document.execCommand('Stop') in Trident abort the parser (the latter not for script-created parsers):
http://hsivonen.iki.fi/test/moz/readystate/window-stop.html
http://hsivonen.iki.fi/test/moz/readystate/document-open-window-stop.html
http://hsivonen.iki.fi/test/moz/readystate/execcommand.html
http://hsivonen.iki.fi/test/moz/readystate/document-open-execcommand.html

Comment 2 Ian 'Hixie' Hickson 2012-07-10 18:56:22 UTC

This may be clearer now that in the WHATWG copy it says both to cancel the navigation (which I think is already clearly defined to just mean aborting that "navigate" algorithm) _and_ abort the document.

Comment 3 contributor 2012-07-18 17:58:59 UTC

This bug was cloned to create bug 18291 as part of operation convergence.

Comment 4 James Graham 2012-07-26 16:08:16 UTC

It is still not clear. In particular when you cancel some other navigation e.g. step 6 of the navigate algorithm.

One interesting case is when the navigation algorithm is invoked from the load handler of the previous navigation (which is not yet mature at that point), as in http://www.hixie.ch/tests/adhoc/html/navigation/unload/same-origin/001.html 

A solution that reproduces the Gecko behaviour is to make "cancel" equivalent to "abort" without the event.

Comment 5 James Graham 2012-07-26 16:14:25 UTC

*** Bug 16800 has been marked as a duplicate of this bug. ***

Comment 6 Ian 'Hixie' Hickson 2012-09-18 22:55:53 UTC

I don't understand what is confusing here. Could you elaborate on some possible interpretations of "cancel" that are possible?

I just mean to stop running the algorithm, the same as is done in various other places in the spec.

Comment 7 Ian 'Hixie' Hickson 2012-12-01 00:45:19 UTC

Ok, having carefully audited the algorithm, I think the only thing that's ambiguous is what happens if you're running the "prompt to unload" subalgorithm and the author does something that cancels the navigation.

I've fixed this by killing all navigations for a doc when prompt to unload is running on that doc. This seems to be what browsers do, conveniently. I've also explicitly said that you finish that step if the algorithm is aborted while you're on it (which can happen in some other cases), and done some other minor cleanup for the case of redirects (where the old text actually had you doing multiple beforeunload events, oops).

I'm marking this FIXED, since I can't see anything else that's ambiguous here. However, I'm happy to believe that I've missed something. If you reopen this, please do include a description of two detectably different behaviours that you both think are conforming to the spec for the same situation, as a way to demonstrate the ambiguity. Thanks.

Comment 8 contributor 2012-12-01 00:46:07 UTC

Checked in as WHATWG revision r7554.
Check-in comment: Try to clear up some ambiguities and errors in the navigation algorithm, and prevent beforeunload from ever navigating its browsing context.
http://html5.org/tools/web-apps-tracker?from=7553&to=7554