ExE Boss Reporter
	Description • 6 years ago

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)