How to add a new scheme?

[elijah (Eli the Bearded)]

Some years ago I wrote an extension to add a new scheme to Firefox. Basically it this scheme just rewrote the URL into a normal supported scheme and then proceeded to load that page. The whole thing was just a short cut.

BUT, what with changes in extension APIs, it no longer works.

I’ve gone through the exercises of build your first / second extension:

1. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Your_first_WebExtension
2. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Your_second_WebExtension

And I notice that the reading the manifest.json documentation, it looks like

protocol_handler can add new protocols, but only if they are of the form “web+foobar” or “ext+foobar”, which isn’t helpful for me. It also isn’t helpful that all it seems able to do is forward a URL to a website. I want to rewrite a URL in javascript, not forward it somewhere.

omnibox can be used to rewrite stuff in the URL box, but only when prefixed with a keyword and space. And it seems to be limited to stuff typed in. The original extension I wrote would work from the command line (firefox ...).

content_scripts won’t do anything to rewrite a URL, and the match rules explicitly won’t handle anything other than a few predefined schemes.

chrome_url_overrides doesn’t appear to add new schemes, just enables hardcoding a few pages.

Is URL rewriting something that has been suppressed in current Firefox? Am I out of luck?

[NilkasG (Niklas Gollenstede)]

Redirecting with the webRequest API may me an option. It really depends on what exactly you intent to do. Could you provide a concrete example of what you want to rewrite as what?

[lidel (Marcin Rataj)]

• Bug 1310427 - protocol handlers (for mailto etc) implements basic redirect-based web+foo handler defined via protocol_handler section of manifest.info. This seems to solve your use case, but as you noted, there is a mandatory web+ prefix.

• Bug 1271553 - Add ability to implement programmable custom protocol handler is still open, you may want to state your use case there, if protocol_handler is not enough.

[elijah (Eli the Bearded)]

Could you provide a concrete example of what you want to rewrite as what?

Rot-13.

uggc://jjj.rknzcyr.pbz/ should resolve to http://www.example.com/.

Looking at the webRequest API documentation, it’s implied that you can only add listeners for cases that MatchPattern will match, which is the same limit as content_scripts

The use case is from URLs in Usenet, where rot-13 is still used as a spoiler hider. Sometimes there will be a block of text like:

http://en.wikipedia.com/wiki/Ordinary_thing

Ebg-13 fubpxvat qrgnvy nobhg beqvanel guvat.

And when rot-13 is applied, it changes to whole body, so it now looks like:

uggc://ra.jvxvcrqvn.pbz/jvxv/Beqvanel_guvat

Rot-13 shocking detail about ordinary thing.

I’d like to be able to open the uggc URL rather than go through another encoding. It’s not a super common need, I’ll admit, and it is just a convenience thing, but still: I’d like it.

Having to do anything to modify the URL by hand, such as add web+ in front, ruins any usefulness of this.

[NilkasG (Niklas Gollenstede)]

I fiddles around with the chrome.webRequest API in Chrome around a year ago. As I recall, if you subscribe to <all_urls>, at least Chrome fires onBefreRequest for pretty much everything entered in the location bar, even if it doesn’t match a known protocol, as long as it doesn’t contain spaces.

If Firefox behaves the same, you should be able to do arbitrary redirects there.