[whatwg] Proposal to extend registerProtocolHandler

[Rich Tibbett]

Rich Tibbett wrote:
> Peter Kasting wrote:
>> On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai<ojan at chromium.org> wrote:
>>
>>> Do any browser vendors agree with this or have objections?
>>
>>
>>> From my work on the Chrome UI side of this, I would very much like to
>>> see
>> something like isRegistered(). This would allow sites to conditionalize
>> requests for the protocol handler. This is important to me because I
>> would
>> also like to experiment (after that point) with requiring a user
>> gesture for
>> this request (much like browsers typically require user gestures for
>> window.open()), so sites cannot hammer the user with requests outside of
>> some sort of interaction-based workflow.
>
> I've also been thinking along these lines for things that require some
> user interaction at the chrome level.
>
> The idea would be to emulate window.open functionality to the point that
> something happens only if a _user-initiated_ click event occurs. If an
> event is invoked by a script synthesizing its event via e.g.
> anchor.click() then that should not invoke any UI stuff. Only if
> window.open is invoked by a user does the popup blocker not kick-in and
> the popup pages open. It would be nice to have that same principle work
> for registerProtocolHandler.
>
> FWIW, I proposed something to the effect you are describing in the W3C
> Contacts API [1]. window.open seems a little under-defined when it comes
> to the pseudo-standard behavior of blocking window.open calls outside of
> a user-initiated event.

The behavior implied in [1] can be demoed against window.open here 
http://jsfiddle.net/nRJrz/3/

Should we document this psuedo-standard UA behavior wrt window.open? It 
would be nice to have a reference of this behavior on which to build 
other interactive UI experiences in the future.

Tested in Opera 11.5, Chrome 12, Firefox 5 and Safari 5.

>
> br/ Rich
>
> [1] http://www.w3.org/TR/contacts-api/#api-invocation-via-dom-events