W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] navigation shouldn't abort if canceled

From: Ashley Sheridan <ash@ashleysheridan.co.uk>
Date: Wed, 02 Feb 2011 20:41:28 +0000
Message-ID: <827a3228-f1bb-47ed-809b-5d118d67414d@email.android.com>
"Boris Zbarsky" <bzbarsky at MIT.EDU> 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.
>
>-Boris

For the links to open a new web page that would actually be handled by an external app. I remember a few years back when Yahoo! Messenger came with such an app that set itself up as your default mail program and opened a new window. It would be obvious it was a separate app if you clicked on the mailto link on a secondary browser that wasn't the system default.

I don't know if webmail clients handle things differently. Does this behaviour ever happen without the help of an external app or a plugin?


Thanks
Ash
http://www.ashleysheridan.co.uk
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Received on Wednesday, 2 February 2011 12:41:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:03 UTC