Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new API for extesnions to register rendering content types #200

Open
RangerMauve opened this issue Jul 20, 2022 · 3 comments
Open

Add new API for extesnions to register rendering content types #200

RangerMauve opened this issue Jul 20, 2022 · 3 comments
Labels
electron Related to electron, might require fixes from upstream enhancement New feature or request extensions Related to web extensions support

Comments

@RangerMauve
Copy link
Member

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.

@RangerMauve RangerMauve added enhancement New feature or request electron Related to electron, might require fixes from upstream extensions Related to web extensions support labels Jul 20, 2022
@fabricedesre
Copy link

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.

@av8ta
Copy link
Contributor

av8ta commented Jul 22, 2022

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?

@fabricedesre
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
electron Related to electron, might require fixes from upstream enhancement New feature or request extensions Related to web extensions support
Projects
None yet
Development

No branches or pull requests

3 participants