[whatwg] Proposal to extend registerProtocolHandler

[Ojan Vafai]

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
>