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

[James Hawkins]

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