[whatwg] Proposal to extend registerProtocolHandler

Rich Tibbett richt at opera.com
Tue Jul 5 00:42:32 PDT 2011


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.

br/ Rich

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



More information about the whatwg mailing list