- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 29 Apr 2011 21:59:10 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 29 April 2011 14:59:10 UTC