= Overview =
Streamline and extend the handling of MIME typed content on the web.
== Motivation ==
** 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
== Requirements ==
== API Changes ==
''list any * 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 made by this feature.''related to streaming content handling* possible internal API changes related to minimizing database duplication
== Extensibility ==
''list work done register{Content,Protocol}Handler are by definition extensibility features. If one wanted to make feature extensible by implement a handler in add-ons & any impact 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 of Firefox'' experience.
== Customization ==
''list changes Similarly, this set of features is entirely related to preferences and customization controls the ability for the feature''users to customize their web experience.
== Performance ==
''list effects on The only performancechange 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, tests used, metrics targeted''it would be good to do some profiling to ensure that this is the case.
== Reliability/Stability ==
We''list effects on reliability/stability, tests used, metrics targeted''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).
== Security ==
The content-handler stuff will definitely need a security review. The [http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers WHATWG Web Apps spec] discusses some of the stuff we''list security impact and link ll need to think about there. We also need to results ensure that any changes made w.r.t. how we interact with OS definitions of content-handlers don't introduce new security reviews''flaws.
== Privacy ==
''list privacy impacts and any tie-ins Any content that a user chooses to user privacy features''have handled by a web app will (or at least could) be disclosed to the operator of the web application.
== Global Audience ==
''list l10n requirements and a11y efforts''Nothing unusual anticipated.
== Web Compatibility ==
''list any known effects on compatibility with websites''We will likely be the first extensive implementor of the register{Content,ProtocolHandler} pieces. This may merit some evangelism to key web application implementors.
== Other ==
= 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.''
== References ==
''links The [https://addons.mozilla.org/firefox/4498/ MIME Edit] addon has some example UI that is more complete than our current UI, though not particularly friendly to external documents that could inform the design of the feature''non-technical users. [http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers WhatWG Web Applications spec]
