WebExtension Proxy API Design
mail at johann-hofmann.com
Tue Jul 12 08:07:45 UTC 2016
I was the one who initially approached implementing the Proxy API as I’d love to see existing Chrome Proxy Extensions ported to Firefox. So I’ll try to explain a bit.
Option A (parity with Chrome) requires us to implement a mechanism where only a single extension at a time can control all the proxy settings of the whole browser. The Chrome API mirrors our browser settings very closely, so this is really simple, the hard part is making sure that other extensions and the user are shown an error when they try to modify the proxy settings, since they’re locked.
Option B would see us implement a interface on top of https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProtocolProxyFilter <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProtocolProxyFilter>, which allows for “stacking” proxies so that theoretically multiple extensions could register their proxy server and it would go through the list to determine which to use. This is completely incompatible with Chrome and has several big limitations as far as I can see, like lack of PAC script support. (Correct me if I’m wrong about this).
I’m strongly against implementing a different API than the Chrome API for Proxies. This would go completely against the original intention of WebExtensions, a common API for all browsers. There are tons of proxy extensions for Chrome that all rely on the PAC script mechanism and I don’t think that any would bother doing the difficult port to nsIProtocolProxyFilter.
Having written one of the most popular proxy extensions for both Chrome and Firefox, I can confidently say that PAC scripts are a very useful mechanic and we only ported to Firefox because we could set the PAC settings using a preference.
The use case for duplicate proxy extensions routing the user alongside each other is almost nonexistent. At ZenMate, if a conflict ever occurred, it was because our users had installed a competing extension that would have overridden our proxy settings, not complemented them. In that case you get a helpful error from the Chrome API which allows you to show a warning to the user. The conflict case is not handled at all in nsIProtocolProxyFilter right now! Proxies that compete with each other have no way to tell.
Is the Chrome model difficult to implement for us? Absolutely. chrome.settings will be a huge drag to work on. We’ll need some sort of registry that accounts for what extension is currently locking which browser preference and restore it on uninstall. It’s the right way to go, though:
- The API is vastly superior for what feels like 99% of extensions out there.
- We will maintain Chrome compatibility
- There are other WebExt APIs that use chrome.settings, and those would be a breeze to implement afterwards
> On 12 Jul 2016, at 07:36, Andrew Swan <aswan at mozilla.com> wrote:
> Matt, your email alludes to some of the differences between the existing Chrome API and the Firefox capabilities but for me and others on the list who aren't familiar with the details, can you explain a bit more about the "existing proxy filter API"? A link to an MDN page for the Firefox side would be helpful but a detailed description about how the two APIs differ would be excellent.
> Dev-addons mailing list
> Dev-addons at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev-addons