[whatwg] Proposal to extend registerProtocolHandler

Michael Davidson mpd at google.com
Tue Jul 5 12:58:22 PDT 2011

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.


On Mon, Jul 4, 2011 at 3:41 PM, Peter Kasting <pkasting at 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 <
> nils at 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

More information about the whatwg mailing list