[whatwg] Proposal to extend registerProtocolHandler
ojan at chromium.org
Fri Jul 8 09:44:03 PDT 2011
On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking <jonas at 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 <ojan at 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
> > 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
> > be able to show it only when actually registered.
> > On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting <pkasting at google.com>
> >> On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote:
> >> > For registration, we could allow _auto-registration_ of protocol
> >> > only if a.) this is the first time the protocol is being registered
> >> b.)
> >> > when the registration request is coming directly from the top-most
> >> > 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
> >> 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
> >> > 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
> >> intended as motivation for discussing various APIs, not as proposed
> >> PK
More information about the whatwg