- From: Rich Tibbett <richt@opera.com>
- Date: Tue, 05 Jul 2011 09:42:32 +0200
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
Received on Tuesday, 5 July 2011 00:42:32 UTC