Thanks for everyone's comments. I'm replying to Nick's message since
he had them rather collected and enumerated.
> UI: I prefer the infobar, as per the arguments above. I don't think this
> will happen frequently enough to be annoying.
This seems to be the consensus.
> UI: Should there be user UI to manage this that doesn't require knowing a
> magic about:protocols url?
More than happy to have one if the UI gurus have something in mind, I
was actively attempting to not change any UI element.
> API: Is there an API to unregister from a protocol?
No, as spec'd a webapp only announces it's availability by calling
registerProtocolHandler when loaded. The UA must provide a mechanism
for removing/announcing registration.
> API: How does the page know it's registered?
Why would it need to know? There's nothing it can change.
> We should probably have a
> separate API for this, so sites can display a more prominent call to action
> when they're not registered.
Beyond the infobar (which should be hidden on return navigations if
the user has previously declined,but always available from
about:protocols), what do you have in mind? Not having a means of
suppressing this will make the site annoying.
> Misc: Should there be some way for native apps to register as protocol
> handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS
> provide this?
The OS provides hooks for some protocols. I mentioned this in the
tail end of the script; I'm not sure how happy users would be to see
Chrome populating their registry with protocol handlers.
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
