[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