1358334 - Need nsIProtocolHandler analog

Status: RESOLVED DUPLICATE of bug 1271553

(WebExtensions :: Untriaged, enhancement)

Description

[Eric Jung [:ericjung]]

nsIProtocolHandler [1] enables the calling of a custom Javascript handler for a custom protocol. For example, I can register a proxy protocol handler and have my addon's Javascript function called whenever a URL with that protocol loads. The legacy FoxyProxy addon uses this for self-configuration.

Two use cases:

* Websites publish lists of proxies in formats like this:

   proxy//:host=proxy.foo.com&port=1080&isSocks=true&enabled=false

The entire format is documented here [2]. I can give examples of websites that do this.

* Some people use this ability to configure FoxyProxy in headless environments like Selenium WebDriver.

Bug 1310427 does not handle these use cases because, if I understand correctly, it only permits a web page to be loaded, not a Javascript handler.

You can see FoxyProxy's implementation here [3]

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProtocolHandler
[2] https://getfoxyproxy.org/developers/proxyprotocol/
[3] http://code.getfoxyproxy.org/Foxyproxy_Firefox/tree/src/components/foxyproxyprotocolhandler.js

Comment 1

[Eric Jung [:ericjung]]

I should also mention that when a proxy:// URL is visited, the Javascript function which changes configuration is not called unless   the user confirms the change by accepting a notificationbox [1]. This prevents accidental configuration changes.

Although I focused on FoxyProxy in the initial comment, one can obviously see the power this can bring to all sorts of addons.


[1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/notificationbox

Comment 3

[Eric Jung [:ericjung]]

This is not a duplicate of bug 1310427. In fact, I specifically opened it because 1310427 does not address this need... unless I don't understand the full capacity of bug 1310427. Is it possible to call a WebExtension (privileged) javascript function with bug 1310427?

Comment 4

[Eric Jung [:ericjung]]

You might consider extending the existing API in bug 1310427 to support this in such a way that it only extends the whatwg.org spec while not breaking compatibility. By extending the existing API, we're not convoluting WebExtensions with small APIs that will be used by a very small subset of extensions.

For example:

https://html.spec.whatwg.org/multipage/webappapis.html#dom-navigator-registerprotocolhandler

the 2nd arg could be a string (URL) or alternatively a javascript function. Just one example; I can think of others.