[whatwg] navigation shouldn't abort if canceled

[Mike Wilson]

Ian Hickson wrote: 
> On Sun, 26 Dec 2010, Mike Wilson wrote:
> > 
> http://www.whatwg.org/specs/web-apps/current-work/#navigating-
> across-documents
> >
> > (as of December 26, 2010)
> > | When a browsing context is navigated to a new resource, the 
> > | user agent must run the following steps:
> > ...
> > | 9.  Abort the active document of the browsing context.
> > ...
> > | 11. Prompt to unload the Document object. If the user refused 
> > |     to allow the document to be unloaded, then these steps 
> > |     must be aborted.
> > 
> > Might this be a bug? (It seems more consistent with other 
> parts of the 
> > html5 spec, and with browsers, to do the abort after the user has 
> > allowed the document to unload.)
> 
> These tests suggest that it's what WebKit does but isn't what Firefox 
> does. I tried testing Opera and IE but other bugs prevented me from 
> getting conclusive results from them.
>    
> http://www.hixie.ch/tests/adhoc/html/navigation/beforeunload/005.html
>    http://www.hixie.ch/tests/adhoc/html/navigation/interrupts/012.html

FWIW, I tried the following tags in a bunch of browsers (including 
IE, Chrome and Safari):

<link rel="stylesheet"
href="http://1.cuzillion.com/bin/resource.cgi?type=css&sleep=5&t=130
8498308451" type="text/css">

<script
src="http://1.cuzillion.com/bin/resource.cgi?type=js&sleep=5&t=13084
98308455" type="text/javascript"></script>

<iframe
src="http://1.cuzillion.com/bin/resource.cgi?type=html&sleep=5&t=130
8498315456"></iframe>

<img
src="http://1.cuzillion.com/bin/resource.cgi?type=gif&sleep=5&t=1308
498315465">

and none of them were aborted on a dismissed (beforeunload prompted)
navigation attempt.

> On Tue, 1 Feb 2011, Mike Wilson wrote:
> >
> > Consequences of the current text are that resource fetches 
> are canceled 
> > for a document when navigating away from it, even if the user then 
> > chooses to cancel the navigation at a "beforeunload" prompt 
> and returns 
> > to the document.
> 
> Fair point. Fixed. The spec now matches Firefox on this.

Thanks Ian, that looks much better now.

Best regards
Mike Wilson