implement registerContentHandler for arbitrary MIME types

NEW
Unassigned

Status

()

Firefox
File Handling
--
enhancement
10 years ago
a year ago

People

(Reporter: dmose, Unassigned)

Tracking

(Blocks: 2 bugs)

unspecified
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

10 years ago
Spun off from bug 372441.

Updated

10 years ago
Blocks: 385101

Updated

10 years ago
Blocks: 372949
No longer blocks: 385101
Target Milestone: --- → Future
(Reporter)

Updated

10 years ago
Blocks: 37294
No longer blocks: 372949
(Reporter)

Updated

10 years ago
No longer blocks: 37294

Comment 1

10 years ago
ログインした時に、必ず警告として表示されます。
動かすことに支障はないようですが…

Comment 2

10 years ago
Created attachment 316428 [details]
Ver 2.0.0.14

[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 行目)
onLoadFunc()

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?

Updated

10 years ago
Attachment #316428 - Flags: approval1.9? → approval1.9-
Comment on attachment 316428 [details]
Ver 2.0.0.14

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?

Updated

9 years ago
Duplicate of this bug: 471370

Comment 5

8 years ago
I think Google Docs Viewer is a good example why this is needed.

Comment 6

7 years ago
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.
Blocks: 673923
Assignee: nobody → netzen
Let's say I want register http://andreasgal.github.com/pdf.js/web/viewer.html 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

Comment 8

5 years ago
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 http://spasche.net/openinbrowser/ 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.
Blocks: 844910

Comment 9

3 years ago
There is a MIME Type blacklist for `registerContentHandler` in the HTML5 specification:
http://www.w3.org/TR/html5/webappapis.html#type-blacklist

That should be used in place of the current Atom & RSS feed focused whitelist:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator.registerContentHandler#Notes

Comment 10

3 years ago
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 https://developer.mozilla.org/en-US/docs/Accessing_the_Windows_Registry_Using_XPCOM . (Detection is as per https://developer.mozilla.org/en-US/docs/How_Mozilla_determines_MIME_Types#ExternalHelperAppService )

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: https://github.com/brettz9/webappfind (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 https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICategoryManager with, e.g., the category "ext-to-type-mapping" set to "foo" to register for "application/x-foo".

Comment 11

3 years ago
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).
You need to log in before you can comment on or make changes to this bug.