1356397 - support content handlers in WebExtensions

Status: RESOLVED DUPLICATE of bug 1457500

(WebExtensions :: Untriaged, enhancement, P5)

Description

[Denis Lisov]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170412100254

Steps to reproduce:

I'm porting Brief, a feed reader, to WebExtensions. A way is needed to add Brief to the list of available feed handlers.

Given the existence of registerContentHandler[1] as a web API (implemented in Firefox for feeds only, bug 391286), it makes sense to mirror the API introduced for protocol handlers in bug 1310427 and create an array of content MIME-type handlers (initially implemented for feeds only).

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerContentHandler

Comment 1

[:shell escalante]

investigating idea

Comment 2

[Shane Caraveo (:mixedpuppy)]

In my previous exploration of adding content handlers I discovered that essentially, beyond feeds, we wouldn't be able to support anything else.  At that point I decided to not bother.  I'd be fine with a content handler capability that mirrors the patch in bug 1310427 (it would likely be almost identical), but we'd have to limit the mime types per WebContentConverter.

https://dxr.mozilla.org/mozilla-central/source/browser/components/feeds/WebContentConverter.js#466

This wont be a priority for us to implement for 57, however I'd be happy to give input and guidance to anyone who wanted to tackle this.

Comment 3

[Denis Lisov]

Is the "feeds only" limitation a fundamental one (almost everything else must not be available for some reason like security or privacy) or a technical one (the current Firefox infrastructure provides no way to do so)?

Anyway, I'm willing to work on this at least for feeds. What do I need to know apart from https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction ?

Comment 4

[Shane Caraveo (:mixedpuppy)]

The feeds only limitation is both security and technical entwined and I don't know the history, but from looking at code I can surmise the following:

A) undocumented security issues or concerns briefly mentioned in code
B) due to (A), general implementation was left unfinished

I spent a lot of time looking at the content handling code, it would have to be reworked to support a generic interface.  Feeds appear well handled at least in code if not UI.

Comment 5

[Shane Caraveo (:mixedpuppy)]

(In reply to Denis Lisov from comment #3)
> Anyway, I'm willing to work on this at least for feeds. What do I need to
> know apart from
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/
> Introduction ?

Oh, and start there and ping me with any questions.

Comment 6

[Shane Caraveo (:mixedpuppy)]

Attachment: exploratory patch contentHandlers

This is an old patch (probably bit rotted) I did when exploring adding content handler support (I was trying to support any mime type, not just feeds).  Some of it may still be useful (e.g. the schema and perhaps some of the ext-contenthandlers.js code).  It also probably illustrates some of the strange code paths that potentially happen with various content handling.

Comment 7

[Denis Lisov]

Oh, thank you for the patch!
I was actually looking at WebContentConverterRegistrar that registerContentHandler uses. What's the reason you're avoiding it?

Comment 8

[Shane Caraveo (:mixedpuppy)]

(In reply to Denis Lisov from comment #7)
> Oh, thank you for the patch!
> I was actually looking at WebContentConverterRegistrar that
> registerContentHandler uses. What's the reason you're avoiding it?

IIRC, and it's been some time since I looked at this so I could be wrong, WebContentConverterRegistrar was limiting to feeds and I was trying to get more general (such as supporting ebook mime types).

Comment 9

[Croydon]

From my understanding if you limit content handlers to RSS you kill add-ons like a Markdown Viewer, e.g. https://github.com/Thiht/markdown-viewer/issues/62

Comment 10

[Shane Caraveo (:mixedpuppy)]

(In reply to Croydon from comment #9)
> From my understanding if you limit content handlers to RSS you kill add-ons
> like a Markdown Viewer, e.g.
> https://github.com/Thiht/markdown-viewer/issues/62

I responded on that issue.  The specific code linked to should be possible given bug 1255894.

Comment 14

[Jonathan Kingston [:jkt] he/him]

If you were porting a feed reader how come registerContentHandler isn't sufficient here?

Comment 15

[Denis Lisov]

Sorry for falling out, due to external deadlines I was unable to get this bug done by Quantum and had to use a workaround in the WebExtension version of the feed reader.

Also it's not quite clear for me what's the way forward and the expected API given the removal of registerContentHandler.

Comment 18

[ExE Boss]

(In reply to ExE Boss from bug 1451983 comment #0)
> Created attachment 8965548 [details]
> W.I.P. schema
> 
> Right now, `protocol_handlers` allows extensions to handle protocols unknown
> to Firefox, `content_handlers` would allow extensions to handle file types
> that are unknown to Firefox.
> 
> # Example use cases:
> - Markdown and other content type viewer extensions:
>   - https://addons.mozilla.org/firefox/addon/markdown-viewer-webext/
>   - https://addons.mozilla.org/firefox/addon/markdown-viewer-chrome/
>   - https://addons.mozilla.org/firefox/addon/gitlab-markdown-viewer/
> - Shumway (yes, I know that it’s not been supported by Mozilla since 2016)
> - PDF.js
> - Many other file type handling extensions…
> 
> # Base requirements for how embedded content should be handled:
> 1. The presence of the extension must be undetectable to the website, to
>    prevent UUID leaks (see bug 1372288), i.e. the website will see the original
>    source in the [src] or [href] attribute and in iframe.contentWindow.location
>   (the last one will see the path that was passed to the `%s` parameter),
>    instead of the extension URL.
> 2. Extensions can only handle content from origins they have access
>    permissions for (possibly optional, given that this doesn’t apply
>    to `protocol_handlers`).
> 
> # Benefits:
> - Extensions won’t need to use hack-ish ways to render content, which don’t
>   even always work (see the Markdown viewer extensions above) or inject
>   <iframe> elements in place of <object> or <embed> elements to act as
>   plug-ins.
> - Might potentially help some system add-ons to migrate away from being
>   bootstrapped extensions (see bug 1449052), for example:
>   - Devtools JSON viewer
>   - XML pretty print (bug 1437956)
>   - PDF.js
>   - Shumway
> 
> # Possible drawbacks:
> - Is essentially a re-implementaion of Navigator.registerContentHandler(),
>   which is why unlike `protocol_handlers`, the current draft of
>   `content_handles` only permits extension pages in the `templateUri` entry.
>  (see https://developer.mozilla.org/docs/Web/API/Navigator/registerContentHandler)

Comment 19

[Caitlin Neiman [:caitmuenster]]

Hi Denis, this has been added to the agenda for the WebExtensions APIs triage on April 16, 2018. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1A7lwSkunTIdPE8FGqYV93oO-2l8xo3GFqTbY1l1QC1w/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 20

[Caitlin Neiman [:caitmuenster]]

Sorry -- the WebExtensions APIs triage will be on April 17, not April 16 as mentioned above. :)

Comment 21

[kernp25]

Old add-ons could use nsIContentHandler [1] or nsIURIContentListener [2].

[1] https://dxr.mozilla.org/mozilla-central/source/uriloader/base/nsIContentHandler.idl
[2] https://dxr.mozilla.org/mozilla-central/source/uriloader/base/nsIURIContentListener.idl

Comment 22

[Mike Conca [:mconca]]

The feasibility, scope, and risks of this feature are being investigated.

Comment 23

[Rob Wu [:robwu]]

The request to support content handling through registerContentHandler has been denied because this API was only limited to feeds, and it has been removed.

Content handling as a feature was accepted, and its implementation is tracked in bug 1457500.
All feedback from this bug and its related duplicates are taken into account.