From MozillaWiki
Jump to: navigation, search


Feature tracking bug


Streamline and extend the handling of typed content on the web.


Our current MIME-type handling has some rough edges that needs to be cleaned up. Additionally, more and more people are using web-applications as their primary way to handle specific types of content (e.g. calendar, mail). It should be possible for web sites to register content-handlers for types other than just RSS.

Use Cases

  • dynamic handoff
    • subscribe to an ICS calendar in a web calendar application
    • properly hand off streaming content (music, video) to a local or embedded player
  • static handoff
    • take an event in an ICS file generated by evite and insert it into a web calendar
    • allow a website to render an Excel spreadsheet into HTML in an iframe
    • hand off a mailto: URL to a web mail app for composition
    • display a news: URL using Google Groups


CON-001a P1 FR Support web services as MIME type & protocol handlers bug 380415, bug 372441
CON-001b P2 FR Minimize/remove local MIME type database for local applications This actually means that we'll pass it up to the OS rather than directly to an application.
CON-001c P3 FR Properly handle streaming content types - embedded or handed off to a helper app
CON-003a P1 NFR Simplify content-handling UI UI is ugly; needs to be less ugly bug 377782
CON-003b P2 NFR Create an easy-to use MIME-type handling configuration system Isn't this the same as the previous item?
CON-003c P3 FR Ability to show or sniff content on-demand and view in plaintext or html or other format instead Need to find a non-scary way to present this to users.


Describe the rough schedule here, linking back to relevant product release milestones, as well as linking to any build/release notes.

Design & Implementation


The plan is to develop this on the trunk of the core Mozilla CVS repository.

API Changes

  • navigator.registerContentHandler() will actually use registrations for non-feed types rather than dropping them on the floor
  • navigator.registerProtocolHandler() will be implemented
  • probable internal API changes related to both of the above
  • possible internal API changes related to streaming content handling
  • possible internal API changes related to minimizing database duplication


register{Content,Protocol}Handler are by definition extensibility features. If one wanted to implement a handler in add-on chrome, that should theoretically Just Work, but if we care about this case, we should explicitly say so to ensure appropriate testing. To some degree, everything else we're doing here is also about enhancing and streamlining the extensibility experience.


Similarly, this set of features is entirely related to the ability for users to customize their web experience.


The only performance change that I anticipate is that web-based content handlers are almost certain to be slower than local ones. I suspect that any overhead incurred by the browser here is likely to be lost in the noise of network latency. That said, it would be good to do some profiling to ensure that this is the case.


We'll need to figure out what the failure mode should be when content is handed off to a website handler that is down. This is particularly interesting in the case of dynamically generated content (e.g. receipts).


The content-handler stuff will definitely need a security review. The WHATWG Web Apps spec discusses some of the stuff we'll need to think about there. We also need to ensure that any changes made w.r.t. how we interact with OS definitions of content-handlers don't introduce new security flaws.


Any content that a user chooses to have handled by a web app will (or at least could) be disclosed to the operator of the web application.

Global Audience

  • Each locale will want to offer multiple default choices for protocol handlers for at least mailto: URLs; perhaps other schemes.
  • Similarly, we should be offering default choices for key MIME-types as well (text/calendar, pdf, etc.).

Web Compatibility

We will likely be the first extensive implementor of the register{Content,ProtocolHandler} pieces. This may merit some evangelism to key web application implementors.


any other implementation or design related documentation

Discussion & Implications

One of the interesting things that will need to be addressed

Caveats / What We've Tried Before

links to previous design documents, discussions, etc.


The MIME Edit addon has some example UI that is more complete than our current UI, though not particularly friendly to non-technical users.

WhatWG Web Applications spec

API request from an extension author for dialog extensibility