16801 2012-04-19 16:04:59 +0000 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? 2012-12-01 00:46:07 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#dom-window-stop P3 normal Unsorted 1 contributor ian hsivonen ian james mike contributor oldest_to_newest 66859 0 contributor 2012-04-19 16:04:59 +0000 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 66936 1 hsivonen 2012-04-23 06:42:30 +0000 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 69795 2 ian 2012-07-10 18:56:22 +0000 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. 71048 3 contributor 2012-07-18 17:58:59 +0000 This bug was cloned to create bug 18291 as part of operation convergence. 71512 4 james 2012-07-26 16:08:16 +0000 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. 71518 5 james 2012-07-26 16:14:25 +0000 *** Bug 16800 has been marked as a duplicate of this bug. *** 74052 6 ian 2012-09-18 22:55:53 +0000 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. 79223 7 ian 2012-12-01 00:45:19 +0000 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. 79224 8 contributor 2012-12-01 00:46:07 +0000 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