[whatwg] Proposal to extend registerProtocolHandler

[Ojan Vafai]

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 <koz at 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
>