Porting a Chrome Extension to Firefox(shinglyu.github.io)
shinglyu.github.io
Porting a Chrome Extension to Firefox
https://shinglyu.github.io/web/2017/08/07/porting-chrome-extension-to-firefox.html
5 comments
I recently ported my do not disturb for Gmail (https://www.dndemail.com) extension from Chrome to Firefox (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.
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.
For my extension 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
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
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.
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
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.
>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.
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.
Case in point, a recent phishing attack on Chrome extension developers: https://arstechnica.com/information-technology/2017/08/after...
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.
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.
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)
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)
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 ;)
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?
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.
Did you submit a webextension or a legacy extension?
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.
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.
Due to this and ff terrible market share there is little reason to develop for ff.
Moz has killed ff with their own incompetence.
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.
The only markets where Firefox is below 25% are those where addons in competing browsers don't exist at all: on mobile.
Seeing https://en.m.wikipedia.org/wiki/Usage_share_of_web_browsers chrome seems to dig other browsers.
That is including mobile. On Desktop, Firefox is still a lot larger, although Chrome has been growing, too.
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.
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
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:
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.