User:Dmose:Fx-Docs:ContentTypeProcessing
Status
- Feature tracking bug
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
- 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.
API request from an extension author for dialog extensibility
