Re: [whatwg] Proposal to extend registerProtocolHandler
On Thu, Aug 25, 2011 at 3:23 PM, Ian Hickson i...@hixie.ch wrote: Will the methods above adequately handle this? I believe from Gmail's perspective, yes. Notifications shouldn't require any clicks at all. They should just work, initially constrained to the browser page, with an in-notification UI to allow the user to decide where the notifications should appear (e.g. only in the browser page, or promote them to desktop level, or promote them to send me an SMS to page me whenever this goes off, or whatever). This would be nice, but is not currently how Chrome works. As far as I know, it's the only browser that supports notifications. I'd love to see it changed. Michael
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Aug 2, 2011 at 5:53 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 26 Jul 2011, James Kozianski wrote:
Here are the use cases I had in mind:
1. Allow sites to conditionally show UI to promote the advantages of
registering the site as a handler.
(requires isRegistered)
2. Allow sites to provide settings screens which allow users to register
/ deregister handlers from within the site.
(requires isRegistered, and deregisterProtocolHandler)
The presence of an ignored list - sites who don't have permission to use
registerProtocolHandler - necessitates Michael Davidson's suggestion
that isRegistered() should return a tri-state value (REGISTERED,
DECLINED, NOTASKED). Otherwise sites that have been 'ignored' by a user
won't be able to tell if they should show their promotional UI or not.
Could you elaborate on what kind of UI we'retrying to enable here?
Based on the above use cases, it seems the API that directly addresses
them is:
navigator.shouldShowHandlerPromo('mailto:') = true/false
navigator.getCurrentHandlerState('mailto:') =
'display UI to unregister'
'display UI to register'
'tell user browser-specific way to re-enable previously declined
registration' (?)
navigator.unregisterHandler('mailto:')
...and equivalent for MIME types. Is that really all that is needed here?
(Ignore the names of the methods, they're not the names I'd use.)
shouldShowHandlerPromo() seems to capture the intent of the isRegistered()
function quite well. I can't think of any valid use cases apart from showing
promotional UI. A concrete example of the kind of UI we're trying to enable
is gmail's notifications UI [1].
getCurrentHandlerState() also seems to be fine. The intended result is that
a web developer can have something like a settings page that lets users
modify their protocol handler settings for that site, eg a form with radio
buttons for enable / disable. Again, gmail has an example of the UI we'd
like to enable [2].
Cheers,
James
[1]
http://t1.gstatic.com/images?q=tbn:ANd9GcSqpKN5FmbWKiC-6e-ptj6KJ_qbiyPuPj2M1YZO2wwIOAf6qdX8
[2]
http://img.technified.net/tf/Gmail-Desktop-notifications-for_14988/gmail-desktop-notification-settings.png
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, 26 Jul 2011, James Kozianski wrote:
Here are the use cases I had in mind:
1. Allow sites to conditionally show UI to promote the advantages of
registering the site as a handler.
(requires isRegistered)
2. Allow sites to provide settings screens which allow users to register
/ deregister handlers from within the site.
(requires isRegistered, and deregisterProtocolHandler)
The presence of an ignored list - sites who don't have permission to use
registerProtocolHandler - necessitates Michael Davidson's suggestion
that isRegistered() should return a tri-state value (REGISTERED,
DECLINED, NOTASKED). Otherwise sites that have been 'ignored' by a user
won't be able to tell if they should show their promotional UI or not.
Could you elaborate on what kind of UI we'retrying to enable here?
Based on the above use cases, it seems the API that directly addresses
them is:
navigator.shouldShowHandlerPromo('mailto:') = true/false
navigator.getCurrentHandlerState('mailto:') =
'display UI to unregister'
'display UI to register'
'tell user browser-specific way to re-enable previously declined
registration' (?)
navigator.unregisterHandler('mailto:')
...and equivalent for MIME types. Is that really all that is needed here?
(Ignore the names of the methods, they're not the names I'd use.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to extend registerProtocolHandler
Hi Ian, Here are the use cases I had in mind: 1. Allow sites to conditionally show UI to promote the advantages of registering the site as a handler. (requires isRegistered) 2. Allow sites to provide settings screens which allow users to register / deregister handlers from within the site. (requires isRegistered, and deregisterProtocolHandler) The presence of an ignored list - sites who don't have permission to use registerProtocolHandler - necessitates Michael Davidson's suggestion that isRegistered() should return a tri-state value (REGISTERED, DECLINED, NOTASKED). Otherwise sites that have been 'ignored' by a user won't be able to tell if they should show their promotional UI or not. Cheers, James On Sat, Jul 23, 2011 at 8:33 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 21 Apr 2011, James Kozianski wrote: I'd like to propose the following changes to the registerProtocolHandler spec. [...] Before I study the proposals in detail, is there a description of the kind of experience we're trying to enable here? What are the UIs we expect to see page use wih registerProtocolHandler()? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to extend registerProtocolHandler
On Thu, 21 Apr 2011, James Kozianski wrote: I'd like to propose the following changes to the registerProtocolHandler spec. [...] Before I study the proposals in detail, is there a description of the kind of experience we're trying to enable here? What are the UIs we expect to see page use wih registerProtocolHandler()? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to extend registerProtocolHandler
I definitely have privacy concerns regarding a isRegistered function. Such a function might be ok in some contexts, but I'd like to avoid it as far as possible. For example I don't think we need to think in terms of the, arguably crappy, UI that browsers currently use. One simple improvement that browsers could do is to simply have UI that shows yes, not now and never. If the user chooses never then no UI would be displayed the next time that the site calls registerProtocolHandler. Similarly, having a unregisterProtocolHandler without a isRegistered function makes a lot of sense to me. I agree it might not let you create the perfect UI, but you can get pretty far. / Jonas On Wed, Jul 6, 2011 at 10:30 PM, Ojan Vafai o...@chromium.org wrote: All the arguments for registering handlers aside, it ought to be possible for a website to provide some UI for deregistering. For example, many users will expect to go into gmail's settings to stop having gmail handle email links. Gmail's help section needing to give users instructions on each browser's UI for deregistering is not a good user experience. If they're going to have a UI for deregistering, it makes sense for them to be able to show it only when actually registered. On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett ri...@opera.com wrote: For registration, we could allow _auto-registration_ of protocol handlers only if a.) this is the first time the protocol is being registered and b.) when the registration request is coming directly from the top-most window context only (i.e. from a web page that users are actually visiting). We can't allow auto-registration in any case (nor was Robert suggesting that), or the protocol is registered to whoever happens to ask first, land-grab style. This is doubly bad if (like Chrome) the UA registers the protocol handler OS-wide. When the user wants to override the default protocol handler then the UA could allow e.g. ctrl-shift-click to force show the protocol handler dialog to the user. These sorts of click modifiers are all taken already. (Ctrl-shift-click means open link in new foreground tab.) Users should be able to easily detach protocol handlers from this list with either [delete] or [delete all handlers for this domain] on this interface. Honestly I think we're getting a bit afield here. It's not really the WHATWG's purview to say precisely what kind of interface UAs should provide. Even my comments about possibly wanting to check for a user gesture were intended as motivation for discussing various APIs, not as proposed specs. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
If offering a potentially registerable api is done via link rel=protocol-handler type=foopy: href=... Then it'd be reasonable for a handling page to return some well known HTTP response (410?) to indicate that the API is no longer supported. The site wouldn't need to call a method, and the user agent would be able to do something reasonable *when* the user cared about the problem. For the case where the site wants the user to change from an old (dying) api to a new api, the site could use some other well known HTTP response (301?). And yes, it seems perfectly reasonable for UAs to collect possible handlers and let the user choose one when the user needs to use one. -- This is, for example, more or less how Windows handles removable media or other forms of content. And it matches more or less how UAs handle RSS feeds and search engines...
Re: [whatwg] Proposal to extend registerProtocolHandler
On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking jo...@sicking.cc wrote: I definitely have privacy concerns regarding a isRegistered function. Such a function might be ok in some contexts, but I'd like to avoid it as far as possible. Just to be clear, you have privacy concerns for an isRegistered function that is same-domain restricted? For example I don't think we need to think in terms of the, arguably crappy, UI that browsers currently use. One simple improvement that browsers could do is to simply have UI that shows yes, not now and never. If the user chooses never then no UI would be displayed the next time that the site calls registerProtocolHandler. Similarly, having a unregisterProtocolHandler without a isRegistered function makes a lot of sense to me. I agree it might not let you create the perfect UI, but you can get pretty far. / Jonas On Wed, Jul 6, 2011 at 10:30 PM, Ojan Vafai o...@chromium.org wrote: All the arguments for registering handlers aside, it ought to be possible for a website to provide some UI for deregistering. For example, many users will expect to go into gmail's settings to stop having gmail handle email links. Gmail's help section needing to give users instructions on each browser's UI for deregistering is not a good user experience. If they're going to have a UI for deregistering, it makes sense for them to be able to show it only when actually registered. On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett ri...@opera.com wrote: For registration, we could allow _auto-registration_ of protocol handlers only if a.) this is the first time the protocol is being registered and b.) when the registration request is coming directly from the top-most window context only (i.e. from a web page that users are actually visiting). We can't allow auto-registration in any case (nor was Robert suggesting that), or the protocol is registered to whoever happens to ask first, land-grab style. This is doubly bad if (like Chrome) the UA registers the protocol handler OS-wide. When the user wants to override the default protocol handler then the UA could allow e.g. ctrl-shift-click to force show the protocol handler dialog to the user. These sorts of click modifiers are all taken already. (Ctrl-shift-click means open link in new foreground tab.) Users should be able to easily detach protocol handlers from this list with either [delete] or [delete all handlers for this domain] on this interface. Honestly I think we're getting a bit afield here. It's not really the WHATWG's purview to say precisely what kind of interface UAs should provide. Even my comments about possibly wanting to check for a user gesture were intended as motivation for discussing various APIs, not as proposed specs. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
On Fri, Jul 8, 2011 at 9:44 AM, Ojan Vafai o...@chromium.org wrote: On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking jo...@sicking.cc wrote: I definitely have privacy concerns regarding a isRegistered function. Such a function might be ok in some contexts, but I'd like to avoid it as far as possible. Just to be clear, you have privacy concerns for an isRegistered function that is same-domain restricted? Yes. / Jonas
Re: [whatwg] Proposal to extend registerProtocolHandler
On 07/06/2011 07:51 AM, Robert O'Callahan wrote: I don't think browsers need to prompt for registerProtocolHandler. Instead, I would simply allow any site to register as a protocol handler for almost anything, and remember all such registration So all the ad sites (which are embedded via iframe or something) would just register all the possible protocols so that some user might accidentally use their site for protocol handling - especially if the site was the first one to register the protocol. Doesn't sound too good. -Olli When the user navigates to a URI whose protocol has had an app newly registered for it since the last such navigation, then prompt the user to choose which app to use. The UI for that prompt would give prominence to the previously-seected app (if any), followed by any newly registered app(s), and would remember the choice. The UI could be modal or non-modal. It seems to me that this approach would address the issues James Kozianski raised in part 1 of his email, obviating the need for an isRegistered() function. Rob
Re: [whatwg] Proposal to extend registerProtocolHandler
On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 07/06/2011 07:51 AM, Robert O'Callahan wrote: I don't think browsers need to prompt for registerProtocolHandler. Instead, I would simply allow any site to register as a protocol handler for almost anything, and remember all such registration So all the ad sites (which are embedded via iframe or something) would just register all the possible protocols so that some user might accidentally use their site for protocol handling - especially if the site was the first one to register the protocol. Doesn't sound too good. I think you could sequester the new app options sufficiently that that would not be worth doing. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Proposal to extend registerProtocolHandler
On Thu, Jul 7, 2011 at 12:53 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Jul 7, 2011 at 6:41 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 07/06/2011 07:51 AM, Robert O'Callahan wrote: I don't think browsers need to prompt for registerProtocolHandler. Instead, I would simply allow any site to register as a protocol handler for almost anything, and remember all such registration So all the ad sites (which are embedded via iframe or something) would just register all the possible protocols so that some user might accidentally use their site for protocol handling - especially if the site was the first one to register the protocol. Doesn't sound too good. I think you could sequester the new app options sufficiently that that would not be worth doing. You could also just deny all registerProtocolHandler() attempts from non-toplevel frames. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Proposal to extend registerProtocolHandler
Olli Pettay wrote: On 07/06/2011 07:51 AM, Robert O'Callahan wrote: I don't think browsers need to prompt for registerProtocolHandler. Instead, I would simply allow any site to register as a protocol handler for almost anything, and remember all such registration So all the ad sites (which are embedded via iframe or something) would just register all the possible protocols so that some user might accidentally use their site for protocol handling - especially if the site was the first one to register the protocol. For registration, we could allow _auto-registration_ of protocol handlers only if a.) this is the first time the protocol is being registered and b.) when the registration request is coming directly from the top-most window context only (i.e. from a web page that users are actually visiting). In all other cases (if you're the nth provider to attempt to register an already registered protocol handler or you're not requesting from window.top) then the UA would ask the user whether they wish to install this handler as the default for the given protocol or not (replacing the previous default handler). For usage, the ideal situation would be for the user to click on a link and be auto-directed somewhere without having to select from multiple providers each time. When the user wants to override the default protocol handler then the UA could allow e.g. ctrl-shift-click to force show the protocol handler dialog to the user. There the user would be free to select any handler that the UA has come in to contact with during the course of the user's previous browsing sessions (i.e. those handlers that the user decided not to set as defaults at the time). Users should be able to easily detach protocol handlers from this list with either [delete] or [delete all handlers for this domain] on this interface. - Rich
Re: [whatwg] Proposal to extend registerProtocolHandler
All the arguments for registering handlers aside, it ought to be possible for a website to provide some UI for deregistering. For example, many users will expect to go into gmail's settings to stop having gmail handle email links. Gmail's help section needing to give users instructions on each browser's UI for deregistering is not a good user experience. If they're going to have a UI for deregistering, it makes sense for them to be able to show it only when actually registered. On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett ri...@opera.com wrote: For registration, we could allow _auto-registration_ of protocol handlers only if a.) this is the first time the protocol is being registered and b.) when the registration request is coming directly from the top-most window context only (i.e. from a web page that users are actually visiting). We can't allow auto-registration in any case (nor was Robert suggesting that), or the protocol is registered to whoever happens to ask first, land-grab style. This is doubly bad if (like Chrome) the UA registers the protocol handler OS-wide. When the user wants to override the default protocol handler then the UA could allow e.g. ctrl-shift-click to force show the protocol handler dialog to the user. These sorts of click modifiers are all taken already. (Ctrl-shift-click means open link in new foreground tab.) Users should be able to easily detach protocol handlers from this list with either [delete] or [delete all handlers for this domain] on this interface. Honestly I think we're getting a bit afield here. It's not really the WHATWG's purview to say precisely what kind of interface UAs should provide. Even my comments about possibly wanting to check for a user gesture were intended as motivation for discussing various APIs, not as proposed specs. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
Peter Kasting wrote: On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafaio...@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
Re: [whatwg] Proposal to extend registerProtocolHandler
Rich Tibbett wrote: Peter Kasting wrote: On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafaio...@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
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, 05 Jul 2011 00:41:13 +0200, Peter Kasting pkast...@google.com wrote: In general, I echo Michael's comment that we follow the notifications model. That means using http://dev.w3.org/2009/dap/perms/FeaturePermissions.html I take it? I am still somewhat dubious about that idea given http://weblogs.mozillazine.org/roc/archives/2011/06/permissions_for.html but on the other hand it is annoyingly hard to find an alternative. :( -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal to extend registerProtocolHandler
For rPH, please don't require a user-initiated click for the call. That's one very annoying thing about notifications - it takes users two clicks to enable them, and every app has to find some suitable in-page UI to ask users to make the first click. Since both notifications and rPH are confirmed by the UA, it seems silly to require a user-initiated click. Prompting for permissions is much less annoying than opening a new window, so I don't think the same standards should apply. It's also very easy for users to prevent sites from asking in the future by just denying the permission. Michael On Mon, Jul 4, 2011 at 3:41 PM, Peter Kasting pkast...@google.com wrote: In general, I echo Michael's comment that we follow the notifications model. On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Right now sites are actually much _more_ annoying without this feature as they just blindly ask you to make them your protocol handler every time. Can UAs not be expected to handle this properly, like they do with repeated alerts? It's not a problem on the UA side, but the web page side. Assume we want to limit action on this call to cases where there's a user gesture (to prevent bad sites from annoying you quite as easily, though I admit it is not a huge roadblock). Now you're Gmail and you want to give the user the ability to register you as a mailto: handler. So you whip up some button that will make the rPH() call and some UI around it that calls attention to it. Without the ability to check if you're already the default handler, you have to show this UI all the time, which is not at all appealing, or else bury it somewhere, which means it will never get seen by most users. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
On 7/5/11 3:58 PM, Michael Davidson wrote: Prompting for permissions is much less annoying than opening a new window That's unclear. Especially if permission grants are persistent. so I don't think the same standards should apply. If anything, persistent permission grants should have a _higher_ bar than opening a temporary pop-up window... -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Jul 5, 2011 at 1:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: so I don't think the same standards should apply. If anything, persistent permission grants should have a _higher_ bar than opening a temporary pop-up window... Granting permission, yes. But just asking for permission? I say it's less annoying because (in Chrome, anyway), the infobar that asks for permission to be granted isn't modal, and the user can continue with her work. The UA should make it as clear as possible what the consequences are of granting persistent permissions and how to turn them off. But requiring an in-page click to trigger the permission in the UA doesn't seem useful to me. If, for example, Amazon wanted to show me desktop notifications I'd just cilck no. I'd rather do that once then have some persistent part of the Amazon UI dedicated to asking me to let it ask for permissions. Michael -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On 7/5/11 4:48 PM, Michael Davidson wrote: Granting permission, yes. But just asking for permission? If the asking for permission can happen in a context in which the user can't tell what's being asked for, it's a really bad idea... I say it's less annoying because (in Chrome, anyway), the infobar that asks for permission to be granted isn't modal, and the user can continue with her work. This is the one reason that permission requests don't have that higher bar yet, yes. The UA should make it as clear as possible what the consequences are of granting persistent permissions That's really difficult if the site asks for a bunch of permissions in a flurry. -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Jul 5, 2011 at 2:00 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/5/11 4:48 PM, Michael Davidson wrote: Granting permission, yes. But just asking for permission? If the asking for permission can happen in a context in which the user can't tell what's being asked for, it's a really bad idea... Can you clarify what you mean? Requiring an in-page click doesn't mean that the user understands either. Malicious pages can just lie in the text. Seems like it's up to UAs to make sure users understand, and requiring an in-page click won't help that. I say it's less annoying because (in Chrome, anyway), the infobar that asks for permission to be granted isn't modal, and the user can continue with her work. This is the one reason that permission requests don't have that higher bar yet, yes. Sadly, they do for desktop notifications. Fortunately, they do not for rPH. :) The UA should make it as clear as possible what the consequences are of granting persistent permissions That's really difficult if the site asks for a bunch of permissions in a flurry. I'm all in favor of UAs throttling or doing whatever needs to be done in order to help the user make educated decisions. I don't believe that requiring an in-page click will help users at all. Michael -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On 7/5/11 5:04 PM, Michael Davidson wrote: If the asking for permission can happen in a context in which the user can't tell what's being asked for, it's a really bad idea... Can you clarify what you mean? Requiring an in-page click doesn't mean that the user understands either. Malicious pages can just lie in the text. Seems like it's up to UAs to make sure users understand, and requiring an in-page click won't help that. Yes, I'm not saying in-page click is a solution. It works for popups, sort of, but I don't think it does for permission request notifications. This is the one reason that permission requests don't have that higher bar yet, yes. Sadly, they do for desktop notifications. Fortunately, they do not for rPH. :) To be clear, I meant a higher bar than popup windows. -Boris
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Jul 5, 2011 at 2:12 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, I'm not saying in-page click is a solution. It works for popups, sort of, but I don't think it does for permission request notifications. To be truly honest, requiring a user gesture probably doesn't work for rPH() because it doesn't actually work for window.open, or allowing executable files to download, or any other purpose we've keyed off in UAs so far. That's because a click is not at all a good indicator of some sort of of user understanding and intent. The only thing it buys you is the possibility that a visible UI change happens immediately after a user's click and thus that in theory the user _might_ be able to guess that the click triggered the UI change. In any case I am not suggesting we spec anything regarding user gestures for rPH() for now, it was an example of something we could try that isn't really possible to consider unless we give webpages some sort of way to check registration. Also, I happen to agree with Boris that prompting for permissions is not, in fact, less annoying than opening a new window. Making prompts be non-modal infobars does not mean they're suddenly friction-free and OK to show all the time. It's much harder to close an infobar, for example (no keyboard shortcuts or OS allowances). And the consequences of a user clicking OK randomly to close a grant permission infobar are much greater than the consequences of a user clicking a popup's close box. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
I don't think browsers need to prompt for registerProtocolHandler. Instead, I would simply allow any site to register as a protocol handler for almost anything, and remember all such registrations. When the user navigates to a URI whose protocol has had an app newly registered for it since the last such navigation, then prompt the user to choose which app to use. The UI for that prompt would give prominence to the previously-seected app (if any), followed by any newly registered app(s), and would remember the choice. The UI could be modal or non-modal. It seems to me that this approach would address the issues James Kozianski raised in part 1 of his email, obviating the need for an isRegistered() function. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
Re: [whatwg] Proposal to extend registerProtocolHandler
In general, I echo Michael's comment that we follow the notifications model. On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Right now sites are actually much _more_ annoying without this feature as they just blindly ask you to make them your protocol handler every time. Can UAs not be expected to handle this properly, like they do with repeated alerts? It's not a problem on the UA side, but the web page side. Assume we want to limit action on this call to cases where there's a user gesture (to prevent bad sites from annoying you quite as easily, though I admit it is not a huge roadblock). Now you're Gmail and you want to give the user the ability to register you as a mailto: handler. So you whip up some button that will make the rPH() call and some UI around it that calls attention to it. Without the ability to check if you're already the default handler, you have to show this UI all the time, which is not at all appealing, or else bury it somewhere, which means it will never get seen by most users. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
Or we could use a link and have the UA only show the option to the user if it feels like it. The UA could choose not to show it if it's already active. It could also choose to only show it if the user has visited repeatedly or whatever. This is closer to ATOM discovery, but it's also a deployed style. On 7/4/11, Peter Kasting pkast...@google.com wrote: In general, I echo Michael's comment that we follow the notifications model. On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Right now sites are actually much _more_ annoying without this feature as they just blindly ask you to make them your protocol handler every time. Can UAs not be expected to handle this properly, like they do with repeated alerts? It's not a problem on the UA side, but the web page side. Assume we want to limit action on this call to cases where there's a user gesture (to prevent bad sites from annoying you quite as easily, though I admit it is not a huge roadblock). Now you're Gmail and you want to give the user the ability to register you as a mailto: handler. So you whip up some button that will make the rPH() call and some UI around it that calls attention to it. Without the ability to check if you're already the default handler, you have to show this UI all the time, which is not at all appealing, or else bury it somewhere, which means it will never get seen by most users. PK -- Sent from my mobile device
Re: [whatwg] Proposal to extend registerProtocolHandler
On 7/1/11, Ojan Vafai o...@chromium.org wrote: Do any browser vendors agree with this or have objections? I don't look forward to being blackmailed by sites into me allowing them to register for X or else I don't get their content. I have a bank which won't let me bank unless I have Java installed, not because banking requires Java (and not because this bank requires Java to do online banking, just because). Testing for features should only be done by using them. It's ok to try to do X and then after time T tell the user: This might work better if you ... registered. It isn't ok to say You can't do X unless you make Y your default Z.
Re: [whatwg] Proposal to extend registerProtocolHandler
On Sun, Jul 3, 2011 at 12:11 AM, timeless timel...@gmail.com wrote: It isn't ok to say You can't do X unless you make Y your default Z. I would prefer to solve this if it actually becomes a problem. Right now sites are actually much _more_ annoying without this feature as they just blindly ask you to make them your protocol handler every time. I think we should solve real usage problems today in preference to leaving them unsolved for fear of a hypothetical later problem that we could easily solve down the road. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
Peter Kasting pkast...@google.com schrieb am Sun, 3 Jul 2011 12:24:17 -0700: On Sun, Jul 3, 2011 at 12:11 AM, timeless timel...@gmail.com wrote: It isn't ok to say You can't do X unless you make Y your default Z. I would prefer to solve this if it actually becomes a problem. Without breaking sites using it properly? That may (or may not) be hard. Right now sites are actually much _more_ annoying without this feature as they just blindly ask you to make them your protocol handler every time. Can UAs not be expected to handle this properly, like they do with repeated alerts? I think we should solve real usage problems today in preference to leaving them unsolved for fear of a hypothetical later problem that we could easily solve down the road. Define “easily”. Lie to the page if it is annoying? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal to extend registerProtocolHandler
Has anyone seen a site that refuses to work unless notifications are active? I suggest that we follow the notification model since it seems to work well for both site authors and users. I imagine that if sites force users to accept notifications or protocol handlers, those sites won't have many users for long. If it does become a problem in practice (which I highly doubt), then yes, having a UA that lies to the site would be one solution. It would take about five minutes to whip up a userscript that replaces calls to registerProtocolHandler with a noop. Michael
Re: [whatwg] Proposal to extend registerProtocolHandler
Do any browser vendors agree with this or have objections? Hixie, this seem OK to you? These additions seem safe, simple and enable sites giving users a better experience. On Wed, Apr 20, 2011 at 11:32 PM, James Kozianski k...@chromium.org wrote: Hi, I'd like to propose the following changes to the registerProtocolHandler spec. 1. Introduce an isRegistered() function. Currently if a site wants its users to register it as a handler for a given protocol it has two options: a) It can call registerProtocolHandler() on page load. (This approach was suggested in [1]) b) It can have a button that the user clicks (or similar) to enact the registration. The former is problematic because the call to registerProtocolHandler will cause the browser's UI to notify them of the registration (or prompt them to make a decision), which is redundant if it occurs on every page load. The latter is problematic because it puts the onus on each site developer to provide the UI to allow the user to make the change. Also, as the site doesn't know whether the user has already registered the given protocol handler, it can't tailor its UI to reflect this. This means the UI either always shows, or never shows, both of which are undesirable. Having an isRegistered() function would allow a site to simply make the RPH call conditionally on load, or to provide a UI for it that reflects the user's current preference. 2. Introduce an unregisterProtocolHandler() function. Such a function is desirable because it allows sites to remove outdated handlers from clients and would enable clients to provide a UI for managing their registered protocol handlers. 3. Require all URL arguments to have the same origin as the page executing the call. This would would make the behaviour of this set of functions more consistent (isRegistered() should only work for same-domain queries, to prevent information leaking). Cheers, James [1] - http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14548.html
Re: [whatwg] Proposal to extend registerProtocolHandler
On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai o...@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. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
From my perspective on Gmail, I would prefer to know if the user hasn't registered because they declined previously or haven't been asked. If they've declined previously, then calling registerProtocolHandler() in today's UAs will not do anything. If I can't detect that state, then they'll keep clicking and I'll keep calling and they'll get frustrated. I'd prefer if isRegistered() was something like registeredState() and returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that really reflects reality. Michael
Re: [whatwg] Proposal to extend registerProtocolHandler
Agree. This seems strictly superior. Just to bikeshed on the name a bit, since this is hanging off the navigator object, the name should probably mention something about protocols, protocolState()? On Fri, Jul 1, 2011 at 2:25 PM, Michael Davidson m...@google.com wrote: From my perspective on Gmail, I would prefer to know if the user hasn't registered because they declined previously or haven't been asked. If they've declined previously, then calling registerProtocolHandler() in today's UAs will not do anything. If I can't detect that state, then they'll keep clicking and I'll keep calling and they'll get frustrated. I'd prefer if isRegistered() was something like registeredState() and returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that really reflects reality. Michael
Re: [whatwg] Proposal to extend registerProtocolHandler
On 07/02/2011 12:25 AM, Michael Davidson wrote: From my perspective on Gmail, I would prefer to know if the user hasn't registered because they declined previously or haven't been asked. If they've declined previously, then calling registerProtocolHandler() in today's UAs will not do anything. If I can't detect that state, then they'll keep clicking and I'll keep calling and they'll get frustrated. I'd prefer if isRegistered() was something like registeredState() and returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that really reflects reality. Shouldn't there be also something like NOTANSWERED, if user hasn't yet decided whether to accept registering or not. Though, I wonder if there is some privacy issue related to isRegistered/registeredState(). Or there is - web app can know whether it is being used as the default protocol handler for some protocol, say mailto: with GMail. But is the privacy issue bad enough to worry about? Safer option would be if registeredState() would just return ASKED or NOTASKED -Olli
Re: [whatwg] Proposal to extend registerProtocolHandler
On Fri, Jul 1, 2011 at 2:58 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 07/02/2011 12:25 AM, Michael Davidson wrote: From my perspective on Gmail, I would prefer to know if the user hasn't registered because they declined previously or haven't been asked. If they've declined previously, then calling registerProtocolHandler() in today's UAs will not do anything. If I can't detect that state, then they'll keep clicking and I'll keep calling and they'll get frustrated. I'd prefer if isRegistered() was something like registeredState() and returned REGISTERED, DECLINED, or NOTASKED. Then I could make a UI that really reflects reality. Shouldn't there be also something like NOTANSWERED, if user hasn't yet decided whether to accept registering or not. I'm not opposed to this for completeness sake. I expect all sites would just ask again in this case. Though, I wonder if there is some privacy issue related to isRegistered/registeredState()**. Or there is - web app can know whether it is being used as the default protocol handler for some protocol, say mailto: with GMail. But is the privacy issue bad enough to worry about? I'm not sure what the privacy issue here is given that we restrict to same-domain. You're already using the site, so it's just whether they can tell that you use them as a protocol handler. I don't see a problem with exposing that. Safer option would be if registeredState() would just return ASKED or NOTASKED -Olli
Re: [whatwg] Proposal to extend registerProtocolHandler
On Fri, Jul 1, 2011 at 3:03 PM, Ojan Vafai o...@chromium.org wrote: I'm not sure what the privacy issue here is given that we restrict to same-domain. You're already using the site, so it's just whether they can tell that you use them as a protocol handler. I don't see a problem with exposing that. FWIW, notifications already exposes this: http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html Seems best just to crib what they already did. Michael Safer option would be if registeredState() would just return ASKED or NOTASKED -Olli
[whatwg] Proposal to extend registerProtocolHandler
Hi, I'd like to propose the following changes to the registerProtocolHandler spec. 1. Introduce an isRegistered() function. Currently if a site wants its users to register it as a handler for a given protocol it has two options: a) It can call registerProtocolHandler() on page load. (This approach was suggested in [1]) b) It can have a button that the user clicks (or similar) to enact the registration. The former is problematic because the call to registerProtocolHandler will cause the browser's UI to notify them of the registration (or prompt them to make a decision), which is redundant if it occurs on every page load. The latter is problematic because it puts the onus on each site developer to provide the UI to allow the user to make the change. Also, as the site doesn't know whether the user has already registered the given protocol handler, it can't tailor its UI to reflect this. This means the UI either always shows, or never shows, both of which are undesirable. Having an isRegistered() function would allow a site to simply make the RPH call conditionally on load, or to provide a UI for it that reflects the user's current preference. 2. Introduce an unregisterProtocolHandler() function. Such a function is desirable because it allows sites to remove outdated handlers from clients and would enable clients to provide a UI for managing their registered protocol handlers. 3. Require all URL arguments to have the same origin as the page executing the call. This would would make the behaviour of this set of functions more consistent (isRegistered() should only work for same-domain queries, to prevent information leaking). Cheers, James [1] - http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14548.html
