WebExtension Proxy API Design
mwein at mozilla.com
Tue Jul 12 23:58:59 UTC 2016
Thank you all for taking the time to share your thoughts!
In terms of importance for existing Chrome add-ons, we know that 3 out of
the top 30 rely heavily on the Proxy API, and in total they have a little
over 15 million users.
Hopefully Johann was able to answer your question regarding the differences
between the two options. Let me know if you'd like any more information.
Thank you for your input! I find what you said very helpful, and at this
point I think Option A sounds like the right way to go here. By any chance
do you know which of the other WebExt API's rely on chrome.settings? I
think it would be nice to know which ones those are for reference.
Since you suggested the possibility of implementing something more
consistent with our built-in proxy filter API, could you take a look at
what Johann said and share some of your thoughts here?
On Tue, Jul 12, 2016 at 1:07 AM, Johann Hofmann <mail at johann-hofmann.com>
> 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
> 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,
> - The API is vastly superior for what feels like 99% of extensions out
> - 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