User:Dmose:Fx-Docs:ContentTypeProcessing

Status

Feature tracking bug

• bug 372949

Overview

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

Motivation

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

Requirements

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.

Schedule

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

Design & Implementation

Documentation

• Content Handling Scratchpad
• User Interface
• Architecture
• Test Plan

Repository

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

Extensibility

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.

Customization

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

Performance

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.

Reliability/Stability

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).

Security

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.

Privacy

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.

Other

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.

References

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