[hanklazard]

I'm really sorry to hear that--it looks like a useful extension and I'm sure you've put a lot of hard work into it.

Naive question to you and to other extension developers here ... how does Firefox do when it comes to this issue? Is it just that the market share is so much lower that it's not worth developing for FF? I ask this as a happy FF user on mac, linux, ios.

[geza]

I tried porting the extension over to Firefox when Firefox switched to WebExtensions, and at the time there were tons of incompatibilities, mostly with Firefox's Shadow DOM implementation (HabitLab is a huge and complicated codebase, porting it is non-trivial - I had an issue tracking it at https://github.com/habitlab/habitlab/issues/137 ). I'm sure it's a valid option for smaller extensions however. At the moment I'm trying to get it accepted on the Edge store, as Edge is much more compatible with Chrome extensions than Firefox.

[jacamera]

Have you tried again with Firefox recently? I'm the developer of an extension that makes extensive use of the Shadow DOM for UI components in content scripts. I recently ported our Chrome-only extension over to Firefox and had a few minor issues but none with the UI. I'm even using React for Shadow DOM UI components and it's been working well in both browsers.

[hanklazard]

I wonder if others are thinking the same re: Edge and whether this will eventually lead to chrome losing users to Edge as useful extensions find a home there.

[dbjorge]

I work for Microsoft on a moderately complex chromium extension. We've investigated porting it to Firefox (we've had a small but nonzero minority of users ask about it, and several of our engineers have a personal interest in it), but it's really hard to estimate ahead of time how much effort it's going to be. Most of the issues are not so bad to fix individually, it's just an unknown-length onion peeling exercise. It's especially challenging when a library/framework you use is impacted by a difference and its maintainers aren't motivated to improve compatibility; some examples of this we've run into include "Firefox's RegExp implementation doesn't support named capture groups" (but the library author doesn't want to make the code less readable by not using them) and "Firefox's auto-size behavior for extension popup UI (what you see when you click am extensions toolbar icon) sometimes sends spurious window resize events when the DOM is modified" (the UI control library we use has behavior to dismiss context menus on window resize, which this breaks).

The most painful incompatibility I've read about was in the Bitwarden extension, which basically doesn't support most operations in Firefox private windows because Firefox intentionally doesn't support getBackgroundPage() from there, and Bitwarden architected their extension to use that for all IPC between their frontend and backend layers. You can avoid that incompatibility by using runtime.sendMessage for that purpose, but they didn't know that at the time they wrote it (there's a warning about it in the MDN docs for getBackgroundPage now, but that warning wasn't there at the time). We happened to have gotten lucky in our extension in that we use sendMessage for the same purpose, but we certainly didn't know about that incompatibility at the time we were making the architectural decision.

Beyond just making it work, our team would also want to be able to automate regression tests against Firefox if we were to officially support it. For a long time, selenium was the most realistic option for that, but we switched away from selenium to puppeteer a year ago due to reliability issues with the former. Now that Firefox support in puppeteer is very recently starting to stabilize, we're hopeful we'd be able to use that, but we haven't tried it yet and it's new enough that we wouldn't expect it to be fully compatible/stable yet.