<div dir="ltr"><div><div><div><div>Thank you all for taking the time to share your thoughts!<br></div><div><br>Andy,<br></div><div>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.<br><br>Andrew,<br></div></div><div>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.<br></div><div><br></div>Johann,<br></div>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.<br><br></div><div>Kris,<br></div><div>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?<br><br></div>Cheers,<br>Matt<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 12, 2016 at 1:07 AM, Johann Hofmann <span dir="ltr"><<a href="mailto:mail@johann-hofmann.com" target="_blank">mail@johann-hofmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">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.<div><br></div><div>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.</div><div><br></div><div>Option B would see us implement a interface on top of <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProtocolProxyFilter" target="_blank">https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProtocolProxyFilter</a>, 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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><b>The use case for duplicate proxy extensions routing the user alongside each other is almost nonexistent.</b> 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.</div><div><br></div><div>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:</div><div><br></div><div>- The API is vastly superior for what feels like 99% of extensions out there.</div><div>- We will maintain Chrome compatibility</div><div>- There are other WebExt APIs that use chrome.settings, and those would be a breeze to implement afterwards</div><div><br></div><div>Cheers,</div><div><br></div><div>Johann</div><div><br><div><blockquote type="cite"><span class=""><div>On 12 Jul 2016, at 07:36, Andrew Swan <<a href="mailto:aswan@mozilla.com" target="_blank">aswan@mozilla.com</a>> wrote:</div><br></span><div><span class=""><div dir="ltr"><br><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">-Andrew<br><br></div></div></span><span class="">
_______________________________________________<br>Dev-addons mailing list<br><a href="mailto:Dev-addons@mozilla.org" target="_blank">Dev-addons@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/dev-addons" target="_blank">https://mail.mozilla.org/listinfo/dev-addons</a><br></span></div></blockquote></div><br></div></div></blockquote></div><br></div></div>