[whatwg] Proposal to extend registerProtocolHandler

[Jonas Sicking]

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.

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