Credit: Craig Deakins / Flickr
I’ve been a happy user of Google’s Chrome browser pretty much since it was launched but not everyone would agree with my browser choice; there are many who prefer Firefox because it’s arguably more open for developers and, many would contend, because of that, more flexible. So, with Mozilla having just announced a major set of changes to Firefox’s add-on architecture, it’s not surprising that users, and notably add-on developers, are not happy. Here’s a summary of what’s going to be different:
Today we are announcing some major upcoming changes to Firefox add-ons. Our add-on ecosystem has evolved through incremental, organic growth over the years, but there are some modernizations to Firefox that require some foundational changes to support:
- Taking advantage of new technologies like Electrolysis and Servo
- Protecting users from spyware and adware
- Shortening the time it takes to review add-ons
To help the add-on development community understand how we will enable these improvements, we are making four related announcements today:
- We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers.
- A safer, faster, multi-process version of Firefox is coming soon with Electrolysis; we need developers to ensure their Firefox add-ons will be compatible with it.
- To ensure third-party extensions provide customization without sacrificing security, performance or exposing users to malware, we will require all extensions to be validated and signed by Mozilla starting in Firefox 41, which will be released on September 22nd 2015.
- We have decided on an approximate timeline for the deprecation of XPCOM- and XUL-based add-ons.
Like Chrome, the new Firefox will use multiple processes to isolate misbehaving content (and, as with Chrome, it’s memory footprint will undoubtedly grow significantly) and it will gain a new API called WebExtensions which will allow “code written for Chrome, Opera, or, possibly in the future, Microsoft Edge [to] run in Firefox with few changes.”
What seems to be really annoying developers is the implications of “signing”:
Starting in Firefox 42, add-on developers will be required to submit extensions for review and signing by Mozilla prior to deployment, and unsigned add-ons cannot be installed or used with Firefox.
Developers, commenting on Mozilla’s post, see two problems with signing. The first will be turnaround time which, if it’s too long, will make releasing and updating add-ons more expensive, complex, and time consuming. That said, as potentially problematic as turnaround time might be, developers appear to be far more concerned with Mozilla’s approvals process. An anonymous comment on Mozilla’s blog post summed the problem up:
Sign up for Computerworld eNewsletters.