Protocol handler for HAR

[E14]

For writing specifications / documentation, I would really like to be able to create a click-able link that opens RESTED. Ideally this would be done through a protocol handler

eg. har:HAR-STRING-BASE64-ENCODED

[E14]

Some reference:

• https://developer.mozilla.org/en/docs/Web-based_protocol_handlers
• https://mike.kaply.com/2011/01/18/writing-a-firefox-protocol-handler/

[eliihen]

Hm.. I see how this would be useful, but I don't know if it is possible.

[https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler](This page) says that using Navigator.registerProtocolHandler you can only register http:// and https:// pages. Notice that RESTED is chrome:// (and soon moz-extension://).

I am not seeing any API in the WebExtensions API that allow registering protocol handlers. Maybe some combination of webRequest with tabs.open could work.

Can't prioritize this very much, too busy. If someone wishes to have a try, feel free. The webextensions branch is running the WebExtension API.

[E14]

I totally forgot about this... Just putting it out there. I understand that you have other things to prioritise of course, maybe I'll do it myself if I find the time :)

Better reference for this I guess:

• https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProtocolHandler
• http://www.nexgenmedia.net/docs/protocol/

[eliihen]

For the record, this may potentially be possible using a background script and the webNavigation API to sniff any navigation events sent using this protocol and open the extension with a query string. Have not tested this, but may theoretically be possible

[E14]

Forgot about it once again :( I'm not actively working on any project requiring documenting REST requests at the moment, so the hurt-level is very low, however, I think you are thinking too complex

I think with Firefox the best bet would still be the protocol handlers API, which does not restrict the target to be HTTP/HTTPs when invoked through manifest.json, it's not stated specifically but it seems it would be possible to register something like ext+har: for a chrome: target.

For Chrome, that seems not supported, but I think the best bet would be modifying page content instead of fiddling with navigation, so with declarative content API, if should be possible to filter for a[href^='ext+har:'] and replace the click handler - or rather probably actually add one. Enough extensions out there that mess with web page rendering, so that should be perfectly possible. Though that API is not in Firefox it seems

[eliihen]

Forgot about it once again :(

No problem, I just went through all the issues and labeled them, putting some notes here and there.

The problem is that the protocol handler API is a legacy Firefox extension API, not the WebExtension API. In Firefox 57, any non WebExtension based extensions will stop working, as per Mozilla's planned deprecation. So there needs to be a WebExtension based solution for this (which would be cross-browser as well, because this is the same API that chrome uses).

But I see that there is a protocol_handlers configuration property in manifest-json, like you mention, which is cool. Have not tried it yet. If it allows opening the extension in a tab, it could be just what is needed for this to work.

[E14]

Well I was curious and just had a bit of fun digging in Firefox sources :) The whole thing is still a bit undocumented.

Seems that something like this will work in Firefox:

/* manifest.json */
{
	"manifest_version": 2,
	"name": "Test-Protocols",
        ...
	"protocol_handlers": [
		{
			"protocol": "ext+har",
			"name": "HAR protocol handler",
			"uriTemplate": "boo.html?%s"
		}
	]
}

Where boo.html would be one of your add-on's html files, so clicking <a href="ext+har:abc123">Clickme!</a> would be resolved like: moz-extension://<<extid>>/boo.html?ext%2Bhar%3Aabc123

Some notes:

• I only tested with a local file:// source html file, so that could be still a limitation.
• I read up on URL length limit, just to be on the safe side... Seems good in Firefox and Chrome (100kB+)
• moz-extension:// as Template will cause an error loading the manifest, while chrome:// will be silently ignored and no handler installed.
• Found useful examples in Mozilla-Central\toolkit\components\extensions\test\mochitest\test_ext_protocolHandlers.html

[eliihen]

Nice, good digging. This actually looks doable now. I'll plan this for the version after the next.

Thanks for the help!