+++ This bug was initially created as a clone of Bug #1356397 +++ This bug tracks the implementation of a content handler API that allows extensions to handle responses and files of a specific MIME type. Unlike bug 1356397, this bug is not tied to a specific implementation direction.

Will this be implemented in a way that would allow for WebExtensions to act as plugins (like what I outlined in bug 1451983)?

(In reply to ExE Boss from comment #2) > Will this be implemented in a way that would allow for WebExtensions to act > as plugins (like what I outlined in bug 1451983)? Yes. The extension should be able to handle content, regardless of whether they are directly loaded in a tab, or embedded through <embed>, <object>, <frame> or <iframe>.

Can we also pass the filename from the content disposition header to the content handler?

The (relevant) response headers will be available to the extension.

Does it work with local files that don't have a known MIME type? https://bugzilla.mozilla.org/show_bug.cgi?id=1341341#c7

I also found this: https://cs.chromium.org/chromium/src/chrome/common/extensions/api/streams_private.idl?type=cs&q=onExecuteMimeTypeHandler&sq=package:chromium&l=55 Maybe, it gives you some ideas?

Maybe, it makes also sense to improve the build-in content sniffer? Like what google has done? https://cs.chromium.org/chromium/src/net/base/mime_sniffer.cc?type=cs&sq=package:chromium&g=0 Firefox content sniffer: https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#409

Hi kernp25, thanks for your enthusiastic comments in this thread. Please note that when you post a new comment, that a few dozen subscribers may receive e-mail notification. If you want to say something without triggering these notifications, just mail me directly (or message me on IRC in the #webextensions channel). That having said; I'm well aware of Chrome's (private) extension APIs and their limitations, and (Firefox's) content sniffing. At this point the requirements and the shape of the API is quite clear, and I "just" need to work out the implementation details. chrome.streamsPrivate is a bad API design choice because it requires extensions to have an active background page and keep hold of the stream in the background page until the page (where the stream is requested) is ready. If we ignore content sniffing, then Firefox extensions can already do something similar with the webRequest.filterResponseData API (at webRequest.onHeadersReceived). Chrome's streamsPrivate API is going to be removed ( https://crbug.com/705114 ) and has been superseded by the mimeHandlerPrivate API (in conjunction with the private mime_types and mime_types_handler in manifest.json): https://chromium.googlesource.com/chromium/src/+/a9d0aa54d940395d2fcb8d74a6e241346cf16913/extensions/common/api/mime_handler_private.idl My approach is more similar to the mime_types/mimeHandlerPrivate API than the streamsPrivate API: the extension specifies the MIME types that it intends to handle in the manifest file, and Firefox will allow the extension to receive the stream directly in the content page rather than the background page. A significant difference is that I try to minimize the permissions of the content handler page. The page itself will appear like a sandboxed page (with the original request's URL and a null origin), and extensions will be able to interact with that page via a content script. This design was chosen to minimize the impact of code execution vulnerabilities in content handlers, and to support the ability to allow other extensions to run code in the page (e.g. accessibility, translations, ...). That would solve the needs of bug 1454760. (In reply to kernp25 from comment #8) > Maybe, it makes also sense to improve the build-in content sniffer? > > Like what google has done? > https://cs.chromium.org/chromium/src/net/base/mime_sniffer.cc?type=cs&sq=package:chromium&g=0 > > Firefox content sniffer: > https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#409 I want that extensions that register a content handler will always receive all responses of that MIME type, which means that content sniffing needs to be accounted for. Beyond this, I have no desire to "improve" Firefox's content sniffer (which is way more complicated than your links suggest: https://github.com/Rob--W/open-in-browser/issues/5 ). (In reply to eight04 from comment #6) > Does it work with local files that don't have a known MIME type? > https://bugzilla.mozilla.org/show_bug.cgi?id=1341341#c7 I'm currently relying on the platform's and browser's MIME database. Unknown MIME types are not a priority in this bug, but if they don't make it in the first version then I'll file a new bug.

(In reply to Rob Wu [:robwu] from comment #10) > My approach is more similar to the mime_types/mimeHandlerPrivate API than > the streamsPrivate API: the extension specifies the MIME types that it > intends to handle in the manifest file Will you allow wildcards? For example, the JSON Viewer is not just loaded for application/json, but also for things like application/vnd.api+json and application/ld+json, according to https://tools.ietf.org/html/rfc6839#section-3.1: > [RFC4627] defines the "application/json" media type. The suffix > "+json" MAY be used with any media type whose representation follows > that established for "application/json". So allowing "application/*+json" would be nice. But https://docs.google.com/document/d/1TNFukZbG34bwcOhXM2KPNwVnr1RcRERRmkO4H438QFs says > If multiple extensions specify the same MIME-type, then the most recently installed one takes precedence. If somebody has a general-purpose "application/*+json" viewer and a specific "application/ld+json" viewer, then the latter should be preferred for "application/ld+json" data, even if it's not the most recently installed one.

(In reply to Oriol Brufau [:Oriol] from comment #11) > (In reply to Rob Wu [:robwu] from comment #10) > > My approach is more similar to the mime_types/mimeHandlerPrivate API than > > the streamsPrivate API: the extension specifies the MIME types that it > > intends to handle in the manifest file > > Will you allow wildcards? For example, the JSON Viewer is not just loaded > for application/json, but also for things like application/vnd.api+json and > application/ld+json, according to > https://tools.ietf.org/html/rfc6839#section-3.1: > > > [RFC4627] defines the "application/json" media type. The suffix > > "+json" MAY be used with any media type whose representation follows > > that established for "application/json". > > So allowing "application/*+json" would be nice. But > https://docs.google.com/document/d/ > 1TNFukZbG34bwcOhXM2KPNwVnr1RcRERRmkO4H438QFs says > > If multiple extensions specify the same MIME-type, then the most recently installed one takes precedence. > > If somebody has a general-purpose "application/*+json" viewer and a specific > "application/ld+json" viewer, then the latter should be preferred for > "application/ld+json" data, even if it's not the most recently installed one. As a developer of such a general-purpose JSON viewer, I'm very much interested in making use of wildcard MIME types. I imagine this would be a separate issue for the way stream converters get registered internally - the last time I tried to use them like that (legacy addon) I don't think it worked. Additionally to the manifest declaration, I would like some programmatic method to register interest in handling a MIME type at runtime. This would allow users of my viewer to define their own MIME types, a feature which I already provide. If this should be a separate bug, so be it - I just thought it was worth mentioning whilst the design was still under discussion.

I was not planning to support wildcards in the list of MIME-types. If you want to support wildcard MIME types, you could change the Content-Type header at the webRequest.onHeadersReceived event, to a type that your extension handles. I'm starting with static registration of content handlers. If there is no support for dynamic registration when this bug is resolved, file a new feature request.

(In reply to Rob Wu [:robwu] from comment #13) > I was not planning to support wildcards in the list of MIME-types. > If you want to support wildcard MIME types, you could change the > Content-Type header at the webRequest.onHeadersReceived event, to a type > that your extension handles. This won't work with file: or data:, though.

I'll defer this work until the next release because it is unlikely for bug 1389628 to be resolved in 64, which is a prerequisite for the new API.

bug 1389628 enabled the feature in Nightly only, so it's not ready for prime time. I'm dropping the priority of this bug, and added a dependency on bug 1362564, because the latter is desirable for performance. Moreover the implementation of content handling would be different/simpler if that bug were to be resolved.