[whatwg] Proposal to extend registerProtocolHandler

[Ojan Vafai]

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
> 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 <pkasting at google.com>
> wrote:
> >
> >> 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
> 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
> >>
> >
>