27 ms·

Porting a Chrome Extension to Firefox

104 points by XzetaU8 9y ago

flanbiscuit 9y ago
TL:DR; because Firefox adopted the Web Extensions format and even links chrome.* to the same browser.* api, so all you need to do is change a couple of things in your manifest.json and you're good to go. What they don't say how long it takes for Firefox to approve your extension. I submitted an extension and I it took almost 3 months to get approved. I got put in a queue of about 300 at the time and the queue moved very slow. I think this is because an actual person is reviewing the extension and not some automated tool (I assume, maybe that live person is using an automated tool and then hand-checking the results)
- a9t9 9y ago
  3 months seems long. We ported our Copyfish extension to Firefox recently, and the approval process took only ~10 days. I think first feedback took about a week. The reviewer replied with constructive feedback and we had to change a few small things. Then it took another 1-2 days for the final approval. So yes, there is a real human being behind it. Or some super-AI ;)
  - saghm 9y ago
    Maybe the issue is that GP posted so many as once the they got flagged as possibly being spam/malicious/other desirable thing and therefore got put into a manual-verification bucket?
- f4rker 9y ago
  Absolutely correct. Even if you just change one line of code it will take weeks to get approved. Totally unacceptable. Chrome approval process is measured in minutes. Due to this and ff terrible market share there is little reason to develop for ff. Moz has killed ff with their own incompetence.
  - Shywim 9y ago
    Because we all know here that Google's automated review is perfect both in Chrome Web Store and in Google Play Store and that their respective support (the same?) is top notch.
  - kuschku 9y ago
    Terrible market share? In many first world countries, 30-40% of desktop browsing market are still running Firefox. The only markets where Firefox is below 25% are those where addons in competing browsers don't exist at all: on mobile.
    - thierryb 9y ago
      Seeing https://en.m.wikipedia.org/wiki/Usage_share_of_web_browsers https://en.m.wikipedia.org/wiki/Usage_share_of_web_browsers chrome seems to dig other browsers.
      - kuschku 9y ago
        That is including mobile. On Desktop, Firefox is still a lot larger, although Chrome has been growing, too.
- kbrosnan 9y ago
  Did you submit a webextension or a legacy extension?
  - flanbiscuit 9y ago
    It was a brand new Web Extension version. I had no interest in making FF extensions in their old format (just didn't want to take the time to learn it). But when they adopted Web Extensions I was able to easily port a Chrome extension over to it.
- Sylos 9y ago
  There's some criteria by which it just goes through without human code review. I don't know what the exact criteria are, but I imagine it's something like if your extension never connects to the internet and doesn't interact with webpages and so on, it's basically impossible for it to be malicious, so gets a pass. But otherwise, yeah, there is someone who actually reads the code. They probably use automated tools as well, but then in addition.
winter_blue 9y ago
I've run into several problems porting a Chrome extension to Firefox. One of the biggest is that if your extension talks to a server (in my case, it was Firebase), and a web page specifies a CSP (Content Security Policy), Firefox applies the CSP to your extension's content scripts as well, whereas Chrome does not. This is a bug that they've acknowledged, but haven't fixed in over a year: https://bugzilla.mozilla.org/show_bug.cgi?id=1267027 https://bugzilla.mozilla.org/show_bug.cgi?id=1267027 This bug makes it very painful to develop an FF extension, as you now need to create both a background script and a content script, talk to the server in the background script, and then have the background script relay information back to the content script. It's ridiculous. The other problem I had, had to do with using libraries. In Chrome, you can just list the library before the script, and it just works. For example, you could have: content_scripts: ['Rx.min.js', 'your_content_script.js'] Above, with Rx.min.js, I was able to refer to Rx without any trouble inside my content script in Chrome. In Firefox, it didn't work. Rx was an undefined variable. The Rx.min.js script was something that you could include in a page with a script tag, so it should have set that variable. Oh well... I ended up having to use webpack to be able to use Rx inside the content script on Firefox. And that isn't the end of my problems. I also had some trouble getting the communication between content page(s) and the background page working. The examples listed in the MDN documentation simply do not work, even when copied verbatim into a new web-ext project... With the upcoming deprecation of add-ons in Firefox 57, and the really buggy state of WebExtensions in Firefox, it's going to be a pandemonium when add-ons support is dropped. WebExtension developers are going to have quite the experience porting their extensions from Chrome to Firefox.
eejdoowad 9y ago
For my extension Saka Key (https://github.com/lusakasa/saka-key https://github.com/lusakasa/saka-key), I decided to use the browser.* APIs on both Chrome and Firefox using Mozilla's web extensions polyfill. https://github.com/mozilla/webextension-polyfill https://github.com/mozilla/webextension-polyfill The biggest challenge for me was addressing browser incompatibilities and Firefox bugs. This is a big one: https://bugzilla.mozilla.org/show_bug.cgi?id=1193394 https://bugzilla.mozilla.org/show_bug.cgi?id=1193394 Another is that Firefox doesn't fire blur events when DOM elements are removed or hidden. The Firefox approval process is slow. Mine took 3 months the first time, < 10 days the second time, and this third time it's taking over a month. Chrome's reviewal process is really nice. It usually takes <30 minutes.
- Sylos 9y ago
  >Chrome's reviewal process is really nice. It usually takes <30 minutes. Nice for the extension developer, but there's a reason for Mozilla's longer review process. They actually sit down human beings to look over the code and that makes all the difference in keeping AMO clean from malware.
  - ChrisSD 9y ago
    Case in point, a recent phishing attack on Chrome extension developers: https://arstechnica.com/information-technology/2017/08/after-phishing-attacks-chrome-extensions-push-adware-to-millions/ https://arstechnica.com/information-technology/2017/08/after...
  - chris_wot 9y ago
    Won't this just decentralise add-on distribution away from the Firefox add-ons store?
    - toyg 9y ago
      Most people never install any extension from third-party sites. As long as Firefox keeps the search features as they are, very few will ever venture outside addons.mozilla.org.
shazow 9y ago
The post ends right before the step I was more interested to read more about: The AMO submission process. When I ported my extension, I spent a couple of days fixing the frontend Chrome code to work on Firefox, but then spent about a full month waiting for the AMO review process and going back and forth with the reviewer through various confusions and miscommunications.
busymichael 9y ago
I recently ported my do not disturb for Gmail (https://www.dndemail.com https://www.dndemail.com) extension from Chrome to Firefox (https://chrome.google.com/webstore/detail/dndemail-do-not-disturb-f/plpeflfgccdjdoalphmpcahkedbabkno https://chrome.google.com/webstore/detail/dndemail-do-not-di...). The moderators at Mozilla initially reviewed the extension within just a couple of days. They didn't approve it and sent me some questions. I answered the questions but it took them 2 weeks to reply. Even though it was slow, I will say, I was very impressed with Mozilla's focus on privacy and user safety (which is what most of their inquiries focused upon). They are clearly living their marketing -- it is not just lip service for them. I will also note that I submitted a similar extension for the Opera browser on July 17 and am still waiting to hear anything from them.

104 points by XzetaU8 9y ago

TL:DR; because Firefox adopted the Web Extensions format and even links chrome.* to the same browser.* api, so all you need to do is change a couple of things in your manifest.json and you're good to go. What they don't say how long it takes for Firefox to approve your extension. I submitted an extension and I it took almost 3 months to get approved. I got put in a queue of about 300 at the time and the queue moved very slow. I think this is because an actual person is reviewing the extension and not some automated tool (I assume, maybe that live person is using an automated tool and then hand-checking the results)

a9t9 9y ago
3 months seems long. We ported our Copyfish extension to Firefox recently, and the approval process took only ~10 days. I think first feedback took about a week. The reviewer replied with constructive feedback and we had to change a few small things. Then it took another 1-2 days for the final approval. So yes, there is a real human being behind it. Or some super-AI ;)
- saghm 9y ago
  Maybe the issue is that GP posted so many as once the they got flagged as possibly being spam/malicious/other desirable thing and therefore got put into a manual-verification bucket?
f4rker 9y ago
Absolutely correct. Even if you just change one line of code it will take weeks to get approved. Totally unacceptable. Chrome approval process is measured in minutes. Due to this and ff terrible market share there is little reason to develop for ff. Moz has killed ff with their own incompetence.
- Shywim 9y ago
  Because we all know here that Google's automated review is perfect both in Chrome Web Store and in Google Play Store and that their respective support (the same?) is top notch.
- kuschku 9y ago
  Terrible market share? In many first world countries, 30-40% of desktop browsing market are still running Firefox. The only markets where Firefox is below 25% are those where addons in competing browsers don't exist at all: on mobile.
  - thierryb 9y ago
    Seeing https://en.m.wikipedia.org/wiki/Usage_share_of_web_browsers https://en.m.wikipedia.org/wiki/Usage_share_of_web_browsers chrome seems to dig other browsers.
    - kuschku 9y ago
      That is including mobile. On Desktop, Firefox is still a lot larger, although Chrome has been growing, too.
kbrosnan 9y ago
Did you submit a webextension or a legacy extension?
- flanbiscuit 9y ago
  It was a brand new Web Extension version. I had no interest in making FF extensions in their old format (just didn't want to take the time to learn it). But when they adopted Web Extensions I was able to easily port a Chrome extension over to it.
Sylos 9y ago
There's some criteria by which it just goes through without human code review. I don't know what the exact criteria are, but I imagine it's something like if your extension never connects to the internet and doesn't interact with webpages and so on, it's basically impossible for it to be malicious, so gets a pass. But otherwise, yeah, there is someone who actually reads the code. They probably use automated tools as well, but then in addition.

winter_blue 9y ago

I've run into several problems porting a Chrome extension to Firefox. One of the biggest is that if your extension talks to a server (in my case, it was Firebase), and a web page specifies a CSP (Content Security Policy), Firefox applies the CSP to your extension's content scripts as well, whereas Chrome does not. This is a bug that they've acknowledged, but haven't fixed in over a year: https://bugzilla.mozilla.org/show_bug.cgi?id=1267027 https://bugzilla.mozilla.org/show_bug.cgi?id=1267027 This bug makes it very painful to develop an FF extension, as you now need to create both a background script and a content script, talk to the server in the background script, and then have the background script relay information back to the content script. It's ridiculous. The other problem I had, had to do with using libraries. In Chrome, you can just list the library before the script, and it just works. For example, you could have: content_scripts: ['Rx.min.js', 'your_content_script.js'] Above, with Rx.min.js, I was able to refer to Rx without any trouble inside my content script in Chrome. In Firefox, it didn't work. Rx was an undefined variable. The Rx.min.js script was something that you could include in a page with a script tag, so it should have set that variable. Oh well... I ended up having to use webpack to be able to use Rx inside the content script on Firefox. And that isn't the end of my problems. I also had some trouble getting the communication between content page(s) and the background page working. The examples listed in the MDN documentation simply do not work, even when copied verbatim into a new web-ext project... With the upcoming deprecation of add-ons in Firefox 57, and the really buggy state of WebExtensions in Firefox, it's going to be a pandemonium when add-ons support is dropped. WebExtension developers are going to have quite the experience porting their extensions from Chrome to Firefox.

eejdoowad 9y ago

For my extension Saka Key (https://github.com/lusakasa/saka-key https://github.com/lusakasa/saka-key), I decided to use the browser.* APIs on both Chrome and Firefox using Mozilla's web extensions polyfill. https://github.com/mozilla/webextension-polyfill https://github.com/mozilla/webextension-polyfill The biggest challenge for me was addressing browser incompatibilities and Firefox bugs. This is a big one: https://bugzilla.mozilla.org/show_bug.cgi?id=1193394 https://bugzilla.mozilla.org/show_bug.cgi?id=1193394 Another is that Firefox doesn't fire blur events when DOM elements are removed or hidden. The Firefox approval process is slow. Mine took 3 months the first time, < 10 days the second time, and this third time it's taking over a month. Chrome's reviewal process is really nice. It usually takes <30 minutes.

Sylos 9y ago
>Chrome's reviewal process is really nice. It usually takes <30 minutes. Nice for the extension developer, but there's a reason for Mozilla's longer review process. They actually sit down human beings to look over the code and that makes all the difference in keeping AMO clean from malware.
- ChrisSD 9y ago
  Case in point, a recent phishing attack on Chrome extension developers: https://arstechnica.com/information-technology/2017/08/after-phishing-attacks-chrome-extensions-push-adware-to-millions/ https://arstechnica.com/information-technology/2017/08/after...
- chris_wot 9y ago
  Won't this just decentralise add-on distribution away from the Firefox add-ons store?
  - toyg 9y ago
    Most people never install any extension from third-party sites. As long as Firefox keeps the search features as they are, very few will ever venture outside addons.mozilla.org.

shazow 9y ago

The post ends right before the step I was more interested to read more about: The AMO submission process. When I ported my extension, I spent a couple of days fixing the frontend Chrome code to work on Firefox, but then spent about a full month waiting for the AMO review process and going back and forth with the reviewer through various confusions and miscommunications.

busymichael 9y ago

I recently ported my do not disturb for Gmail (https://www.dndemail.com https://www.dndemail.com) extension from Chrome to Firefox (https://chrome.google.com/webstore/detail/dndemail-do-not-disturb-f/plpeflfgccdjdoalphmpcahkedbabkno https://chrome.google.com/webstore/detail/dndemail-do-not-di...). The moderators at Mozilla initially reviewed the extension within just a couple of days. They didn't approve it and sent me some questions. I answered the questions but it took them 2 weeks to reply. Even though it was slow, I will say, I was very impressed with Mozilla's focus on privacy and user safety (which is what most of their inquiries focused upon). They are clearly living their marketing -- it is not just lip service for them. I will also note that I submitted a similar extension for the Opera browser on July 17 and am still waiting to hear anything from them.