Add new API for extesnions to register rendering content types
RangerMauve opened this issue · 3 comments
It'd be useful to enable extensions to register themselves as handlers for certain mime types. e.g. for a JSON viewer or a GLTF file renderer.
This could use some Chrome internals that used to be used for plugins or we could hack this in the web request layer.
Might be useful to define it on the navigator
object for pages in general. 🤔
Not sure how hard it would be for mobile.
A few thoughts (before I forget!) : one thing is to decide if that should be a web-ext API, or to hook something to navigator
instead. I tend to think that it would be overall easier to use a web-ext API because that would guarantee that the handler code is installed and can't fail to load.
The second thing is to figure out the API itself. Gecko has an internal API to convert data from a content type to another (https://searchfox.org/mozilla-central/source/netwerk/streamconv/nsIStreamConverter.idl) which basically boils down to "here are some bytes, and a listener you can send your new bytes to". There is also https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData that could be a good model to be inspired by.
This could use some Chrome internals that used to be used for plugins or we could hack this in the web request layer.
I didn't know there were plugins! Just extensions aka addons. In #197 we're talking about navigator.registerprotocolhandler which seems like a good way to have a webapp located at an http host take control of protocol links while we are on that domain. But with p2p cypherlinks we aren't really at a location (host server on a domain)... ideally our webapps can be hosted on ssb, hyper, ipfs etc, but that doesn't give us a place quite like the oldweb does:
The Navigator method registerProtocolHandler() lets websites register their ability to open or handle particular URL schemes (aka protocols).
ssb for instance has urls like ssb://message/sha256/U4CruGH_upVAD2IUsnu1q3NFL2jZKLKczH2QJn_tu_w=
so of course the browser thinks the host is message
. I have a problem at the moment where I'm trying to load the replayweb serviceworker so I can embed archived websites in ssb posts. It's trying to load from ssb://message/replay/sw.js
which doesn't really make sense!
I feel like #197, #198, and #200 are all talking essentially about the same problem. What happens when you go from a web address pointing to a dns name and hence to a server, to pointing to content-addressed cypherlinks? I think Paul did some work on this problem in beaker? Names pointing to cypherlinks?
"here are some bytes, and a listener you can send your new bytes to"
This is intriguing @fabricedesre, so if I'm understanding correctly, instead of an extension highjacking the rendering of a whole page we could provide an api to say, convert from markdown to html, that any extension/link could make use of? Instead of having to develop or bundle it themselves?
This is intriguing @fabricedesre, so if I'm understanding correctly, instead of an extension highjacking the rendering of a whole page we could provide an api to say, convert from markdown to html, that any extension/link could make use of? Instead of having to develop or bundle it themselves?
Yes, I would rather implement something similar to a fetch event handler that just deals with data, and let it flow through the regular rendering pipeline. Of course there are edge cases to deal with, eg. what happens if several web-ext register for the same content-type, etc.