[whatwg] navigation shouldn't abort if canceled

[Ian Hickson]

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


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.


On Wed, 2 Feb 2011, Boris Zbarsky wrote:
> On 2/2/11 3:22 PM, Michael Nordman wrote:
> > That does sound like a bug? I'd be curious to know what the reasoning 
> > was for the existing sequence of steps.
> 
> From what I can tell, current browser behavior.
> 
> > Step 10 looks out of place too...
> > 
> > "10. If the new resource is to be handled using a mechanism that does
> > not affect the browsing context, e.g. ignoring the navigation request
> > altogether because the specified scheme is not one of the supported
> > protocols, then abort these steps and proceed with that mechanism
> > instead."
> > 
> > Aborting the active document sounds like an undesirable side affect on
> > the browsing context for mailto links.
> 
> I suspect that again this is current browser behavior.
> 
> Note that in some cases mailto: links will load a web page (and thus 
> abort the document they were in).  So it may be worthwhile to have them 
> always abort it, for consistency.

Maybe. I could change this back, but it doesn't seem like a huge issue. I 
mean, opening a link in a background tab doesn't stop a page loading, but 
opening the same link in the same tab does, which seems equivalent to this 
mailto: case. So consistency is never going to be perfect.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'