[whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents

[Brett Zamir]

On 2/16/2012 7:39 AM, James Hawkins wrote:
> We, the designers of the Web Intents draft API, have always seen Web
> Intents as a superset of the functionality provided by
> registerProtocolHandler (RPH) and registerContentHandler (RCH).  To
> follow this to the logical conclusion, we should be able to provide
> functionally equivalent counterparts to RPH/RCH in Web Intents.  This
> proposal provides a means of deprecating RPH/RCH, replacing this
> functionality with equivalent functionality from Web Intents.
>
> For reference RPH/RCH are documented at [1].  The current draft of the
> Web Intents API is at [2].
>
>
> registerProtocolHandler
> ===================
>
> The registerProtocolHandler() method allows Web sites to register
> themselves as possible handlers for particular schemes.
>
>   void registerProtocolHandler(DOMString scheme, DOMString url, DOMString title);
>
> We propose the addition of a 'scheme' attribute to the Web Intents
> service registration to handle this use case.
>
>   <intent scheme="mailto">
>
> * |scheme| is the same as specified for RPH.
> * If |scheme| is specified, |action| *should* (must?) be ignored.
>
> Thus, with this proposal, when the user clicks a "mailto:" link, the
> UA will internally create a new intent containing the scheme and the
> URL parameters as the data in the payload.  This payload will be
> delivered to the service the user picks.  Note we’re considering
> specifying the UA may optionally decode the parameters into the
> |extras| object.
>
> Given the following anchor on mypage.com:
>
> <a href="mailto:me at mypage.com?bcc=support at mypage.com&subject=testing">
>
> the UA will deliver the following payload to the selected service:
>
> {
>    type: “text/plain”,
>    scheme: “mailto”,
>    data: “mailto:me at mypage.com?bcc=support at mypage.com&subject=testing”,
>    extras: {
>      bcc: “support at mypage.com”,
>      subject: “testing” }
> }
>
> Open question: should we use the same whitelist of schemes used by RPH?
>
>
> registerContentHandler
> ===================
>
> The registerContentHandler() method allows Web sites to register
> themselves as possible handlers for content in a particular MIME type.
>
>   void registerContentHandler(DOMString mimeType, DOMString url,
> DOMString title);
>
> We propose modifying the relationship between the |action| and |type|
> attributes to specify that if |action| is not specified and |type| is
> specified, the action is implicitly 'view' and the service must be
> shown in the picker when the UA encounters content of matching MIME
> type.
>
>   <intent type="image/png">
>
> The above registration would register the service to handle content of
> MIME type "image/png".
>
> When the UA loads a resource of type "image/png", it sends the type
> and content to the service in the payload.
>
> {
>    data: pngImageContent,
>    type: “image/png”
> }
>
>
> isProtocolHandlerRegistered / isContentHandlerRegistered
> =============================================
>
> There are serious fingerprinting issues with these methods, and when
> contemplating analogous methods for Web Intents, we thought long and
> hard about the fingerprinting issue.
>
> As spec'ed a site could call registerProtocolHandler('web+uniqueID',
> ...) where uniqueID is unique to a user.  The site could then call
> isProtocolHandlerRegistered with that matching 'web+uniqueID' to
> verify who the user is.
>
> One of the use cases for these methods is to allow a client site the
> ability to show alternative UI for protocols/content that are not
> capable of being handled by any service.  Web Intents also requires a
> solution for this use case, as showing an empty picker* is a
> non-starter.
>
> * The picker refers to the UI in the UA that shows registered services
> for a given intent, allowing the user to pick which service to
> activate.
>
> Instead of creating analogous functionality of these methods for Web
> Intents, we decided to tackle the problem state of an empty picker.
> The proposed solution is to allow a client site to suggest a service
> (URL) that is displayed by the UA in the picker.  The
> |suggestedService| parameter is optional.
>
>   startActivity(..., suggestedService);
>
> In addition declarative registration removes the need to fashion
> registration as:
>
> if (!isProtocolHandlerRegistered(x))
>    registerProtocolHandler(x);
>
> The work of maintaining that state is displaced to the UA.
>
>
> unregisterProtocolHandler / unregisterContentHandler
> ===========================================
>
> The analogous functionality for these methods in Web Intents already
> exists and is the same as the removal of any type of service: remove
> the declarative registration from the content, and the UA will
> unregister the service as a handler.
>
>
> [1]http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
> [2]http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html
>
> Thanks,
> James
>

I like this very much, especially since it seems it ought to allow for 
type-awareness with protocols (e.g., handling only part of the urn: 
protocol). I am also glad the current spec seems to allow for 
specification of multiple defaults.

One aspect I do not find made explicit here is whether the invocation of 
another application is to occur asynchronously within the client app (as 
appears to me to be the case with other (non-scheme) Web Intents) or, as 
would seem more likely, whether the use of the "scheme" attribute will 
always prompt the opening of a new window/tab. I do strongly support the 
ability to open in a new page since it allows for bookmarkability.

I would also like to reiterate two requests I made earlier here, 
especially given the potential for the deprecation you mention, that 
<a/> be given:
1) An attribute of higher precedence than "href", to allow user agents 
to still have a fallback if they do not support this attribute or if the 
user opts not to utilize any of the protocol handlers and wishes to 
visit a simple hard-coded non-protocol-aware website provided by the web 
author. One should not need JavaScript enabled to take advantage of 
links, even while experimenting with new protocols.
2) An attribute of lower precedence than "href" which allows listing of 
additional hard-coded non-protocol-aware websites as right-click options 
for this URL. Perhaps the "contextmenu" attribute would be sufficient 
for this, however, if it can detect the link being right-clicked 
(ideally as part of the event), though I think a simple non-JavaScript 
option ought to be helpful.

Best wishes,
Brett