Closed Bug 391286 Opened 13 years ago Closed 2 years ago

implement registerContentHandler for arbitrary MIME types


(Firefox :: File Handling, enhancement)

Not set





(Reporter: dmose, Unassigned)




(1 obsolete file)

Spun off from bug 372441.
Blocks: 385101
Blocks: 372949
No longer blocks: 385101
Target Milestone: --- → Future
Blocks: 37294
No longer blocks: 372949
No longer blocks: 37294
Attached file Ver (obsolete) —
[Exception... "Component is not available" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSessionStore.js :: sss_saveState :: line 1753" data: no]
(無題)()prototype-1.4.0.j... (549 行目)
these()prototype-1.4.0.j... (83 行目)
getTransport()prototype-1.4.0.j... (550 行目)
initialize("/script/tree_win.js", Object method=get evalScripts=false)prototype-1.4.0.j... (624 行目)
create()prototype-1.4.0.j... (20 行目)
treeLoadStart("win", "/win/art/graphics/edit/")tree_onoff.js (83 行目)

oState.session = { state: ((this._loadState == STATE_RUNNING) ? STATE_RUNNING_STR : STATE_STOPPED_STR) };
Attachment #316428 - Flags: review+
Attachment #316428 - Flags: approval1.9?
Attachment #316428 - Flags: approval1.8.1.15?
Attachment #316428 - Flags: approval1.8.0.15?
Attachment #316428 - Flags: approval1.9? → approval1.9-
Comment on attachment 316428 [details]

Please don't grant review on your own patches. Additionally, please do not request approval on patches that are clearly not reviewed and have no clear statement to what they do (and have nothing to do with the bug they're attached to).

Clearing review, approval, and marking this as obsolete.
Attachment #316428 - Attachment is obsolete: true
Attachment #316428 - Flags: review+
Attachment #316428 - Flags: approval1.8.1.15?
Attachment #316428 - Flags: approval1.8.0.15?
Duplicate of this bug: 471370
I think Google Docs Viewer is a good example why this is needed.
This would be great to be able to automatically open application/x-tinylog files (a log format I developed for a library of the same name) in a viewer for said files I have created.
Assignee: nobody → netzen
Let's say I want register as the content handler for application/pdf files coming from everywhere on the internet, would it be possible or the same-origin policy will prevent that?
Assignee: netzen → nobody
Every week someone develops HTML+JavaScript to handle another file format: pdf, OpenDocument, jpeg2000, swf, webp, mp3, webm, swf again, flac, etc.  Yet Firefox won't let me tell it "use this URL to handle this format."  The absence of this feature is holding the browser back, and it's forcing users to mess with saving locally then launching native applications to handle formats *that their browser is perfectly capable of presenting*!  All this innovation is kept out of the hands of users and only accessible on a handful of demo web sites that incorporate the code.

Until this core feature is somehow addressed, maybe someone could write a tutorial explaining how to package HTML+js that handles a mimetype into an extension, based on how pdf.js does it.  Or maybe someone could write a meta-extension like that lets you nominate web sites (or their code saved locally) to handle mime types.  Looking at the 400 dense lines of code in pdf.js' components/PdfStreamConverter.js it seems quite complex to hand a stream off to a viewer.html for processing.
There is a MIME Type blacklist for `registerContentHandler` in the HTML5 specification:

That should be used in place of the current Atom & RSS feed focused whitelist:
Is there any timeline for implementation, or if this is competing with Web Intents or its successors, is there anywhere the progress can be tracked? I agree with comment 8 that this functionality is critical but such web-based extensibility seems perpetually stalled.

Please let me know if this would require a new bug, but I think the handling of arbitrary MIME types would be much more useful if the user could control files opened from the file system (better than the arcane registry editor on Windows hopefully!) and define new MIME type-file extension associations, whether for OpenWith or default opening for files from the desktop (if not allow sites to suggest associations with user confirmation of non-blacklisted MIME types).

This looks like it would be doable for Windows through . (Detection is as per )

FWIW, I've taken a somewhat different approach to allowing file types to be opened (at least from the desktop) in a web app of choice: (currently Windows only).

Also in reply to comment 8, I haven't worked with content types, but it looks like you need to add a category entry using with, e.g., the category "ext-to-type-mapping" set to "foo" to register for "application/x-foo".
And just in case anyone says that local file content types is the business of the desktop and not the browser, I'd like to point out that the lack of an easy way to define associations (whether for particular files or file extensions), whether OpenWith or default opening, web apps cannot become first class citizens as with native apps, and the data silo model cannot be replaced with the app-agnostic possibilities available to native apps on the desktop but not to web apps for desktop files (or remote files).
Depends on: 1398169
As of Bug 1460481 we should WONTFIX this.
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.