[whatwg] navigation shouldn't abort if canceled
michaeln at google.com
Wed Feb 2 12:22:48 PST 2011
That does sound like a bug? I'd be curious to know what the reasoning
was for the existing sequence of steps.
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
Aborting the active document sounds like an undesirable side affect on
the browsing context for mailto links.
On Tue, Feb 1, 2011 at 11:07 AM, Mike Wilson <mikewse at hotmail.com> wrote:
> No comments so far on this issue so I'll describe it a bit more.
> 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.
> Best regards
> Mike Wilson
> Mike Wilson wrote on December 26, 2010:
>> (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.)
>> Best regards
>> Mike Wilson
More information about the whatwg