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:
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.
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)
Due to this and ff terrible market share there is little reason to develop for ff.
Moz has killed ff with their own incompetence.
The only markets where Firefox is below 25% are those where addons in competing browsers don't exist at all: on mobile.
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.
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.
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.
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.