Firefox, developed by the Mozilla Foundation, is a free and open source browser available for Windows, MacOS and Linux, as well as Android through ‘Firefox for Android’ and iOS through ‘Firefox Focus’. Development began in 2002, and market share peaked at 32% towards the end of 2009, before beginning a steady decline over the following years due to competition from Google Chrome.
Firefox is still my own personal browser of choice, although I do regularly use several for assorted website testing purposes. One of the most appealing and enduring aspects of Firefox has been the great diversity of plugins that allow the entire user experience to be customized, and to a degree not yet matched by other mainstream browsers.
Mozilla plans to release the next major version of Firefox on November 14 2017. Firefox 57, codenamed Firefox Quantum, marks the next phase of Mozilla’s plan to revitalize the browser, both in terms of speed, performance and hopefully market share. Firefox Quantum boasts double the speed with their new engine, while using 30% less memory. But, while this all sounds great on paper, it does come at the cost of forcibly retiring the ‘legacy’ plugin system.
Project Quantum was announced in October 2016 with the goal of revamping the Gecko engine, which it inherited from Netscape, by leveraging tech from their Servo research project. The new Quantum engine, coded in Rust and C, promises to be faster and more stable. Firefox Quantum incorporates several smaller projects that improve parallelisation and GPU offloading within Firefox.
Some of the improvements have already been implemented with recent versions of Firefox, such as Firefox’s ability to utilize multiple processes and features such as WebAssembly and WebVR. Plenty has been achieved already, but Firefox Quantum is an amalgamation of a number of projects with even more yet to come, such as Flow, DOM and Render.
Without delving into the technicalities too deeply, Firefox Quantum will, on average, be twice as fast when compared to Firefox from a year ago. Mozilla boast that speeds should be comparable to Google Chrome while using 30% less memory. It takes advantage of multiple CPU cores and threads, thanks in part to the new Quantum CSS rendering engine.
Version 57 will also introduce a refreshed UI experience, through Project Photon, to improve usability. This new design aims to be minimalist, and integrates square tabs, smooth animations and a user library for access to components like Pocket, tabs, downloads, bookmarks, screenshots, and history. It will also play nicely with high DPI displays and touchscreens.
WebExtensions Plugin API:
Firefox 57 also marks a major departure on one more front. Part of Mozilla’s drive to improve sagging market share through Project Quantum, involves improving Firefox’s speed and performance by completely replacing the plugin API systems. They see this as an unfortunate but necessary move.
The legacy plugin system was predominantly implemented through the XUL and XPCOM application programming interfaces (APIs). These APIs gave plugins deep access to the browser’s internal functionality, allowing them to manipulate almost any aspect or behavior of the browser. This allowed Firefox users a great deal of customizability through the addon system, allowing them to build a powerful browser experience tailored to their exact needs.
The WebEx problem:
Mozilla claim that this move boosts both the performance and security of Firefox but, crucially, the new WebEx API does not allow addons the same degree of access to and interaction with Firefox’s core. Existing ‘legacy’ plugins are not compatible with the newer API and need to be rewritten from the ground up. Users of legacy plugins have been receiving alerts on their addons/extensions page for a while now, informing them which plugins will no longer be compatible once the move to version 57 happens.
The situation is perhaps not as dire as it seems at first glance, because Firefox’s roadmap is planned far in advance and plugin developers have known about this impending change for over a year. Having said that, developers have only been able to get their hands on the API specifics much closer to release. Nevertheless, at the time of writing, many of the popular addons are either WebEx-ready or have separate variants that are compatible with WebExtensions.
There would be no problem if this was the end of the story. Unfortunately, there are many plugins that are no longer supported or have long been abandoned, even though they are otherwise fully functional. These are likely to never see the required code update unless the original developer returns or another takes up the mantle and forks the code. In other words, these plugins will effectively be killed off when the user updates. This result will not be particularly palatable to users, especially if there is no suitable plugin replacement available that retains the same, or similar, functionality.
Furthermore, some plugins just may not be able to be updated at all, even if the developer wishes to do so and has the time to rewrite the code from scratch. The newer WebEx API is far more restrictive than the legacy APIs that came before it and may not grant the developer the necessary access to Firefox’s core to allow the plugin to function. Examples already exist of this, and there are some other instances where the developer has needed to release greatly stripped-back versions.
To try to mitigate this impending plugin apocalypse, Mozilla has collated a bunch of resources for users searching for replacement extensions. A website exists, called ‘Are we WebExtensions yet’, that tracks the status of the most popular plugins and suggests suitable replacements for those that are not WebEx-ready. A full list of Firefox 57 compatible plugins is located here. Community-driven threads also exist on the Mozilla forums and Reddit.
There is a good chance most users will lose some extensions if they update to Firefox 57. Ultimately, Mozilla have no obligation to plugin developers or end-users, but this striking lack of backwards compatibility is likely to anger some. A certain degree of outrage is anticipated, following the launch of Firefox 57, from those that were completely unaware of the situation.
However, on a more positive note, there are still several avenues open to those stuck in this conundrum. Users of Firefox can opt for any one of the following four options.
- The first and most obvious is to not upgrade at all, and keep running version 56.x of Firefox. However, this is not recommended for several reasons, with the most obvious being that you will miss out on security updates. The browser is one of the most prevalent vectors for distributing malware so keeping on top of browser updates should be treated as a necessity. Old software tends to have widely publicised exploits and vulnerabilities so should be avoided.
- Another option is to switch to a different browser. Firefox is open source and developers can freely fork the project in order to maintain compatibility with legacy addons if they wish. There are several examples of browsers based on forked Firefox code, some of which intend to continue supporting legacy addons. Of course, you also have the option of switching to a completely different browser, such as Google Chrome (the most popular), if it meets your needs. Some of the most popular plugins exist in a cross-platform manner and have support for multiple widely-used browsers.
- The third option is just to upgrade to Firefox 57 anyway and accept that legacy plugins will be completely disabled. Perhaps you do not make extensive use of plugins and see them as a secondary consideration over a faster browser core experience. Or maybe the plugin developers servicing the main addons you use have already updated them to be WebEx compatible and any remaining legacy ones are not crucial to your daily use. Whatever the reasons, updating Firefox will always offer you the latest features, fastest performance, and most secure experience.
- The final choice, and the one I have opted for, is to instead delay the decision until June 2018 by switching to the ESR version of Firefox. ESR stands for Extended Support Release, and it allows Mozilla to support business or education needs for a stable version with a long support life cycle. Version 52.x of Firefox ESR will continue to be supported with security-only updates until June 2018. Hopefully, by delaying the update to a WebEx-only version, it allows the plugin developers some additional time to rewrite their code, or even new developers the time to fork existing plugin code from abandoned projects.
Several browsers exist which are based on forked Firefox code, but these are far smaller projects by comparison. A potential drawback to using these browsers, is that development can move at a slow pace. There are currently two main open-source forks of Firefox that still allow the use of legacy extensions – Pale Moon and Waterfox.
Pale Moon’s codebase uses version 38 of Firefox ESR as a foundation. In other words, it far behind current iterations of Firefox. This is not necessarily a bad thing, and the team has confirmed that they will continue to maintain XUL, XPCOM and NPAPI addon capabilities. There can be some issues with some Firefox addons, but the ‘Moon Tester Tool’ addon for Pale Moon can be used to allow ‘Not compatible with Pale Moon’ addons to install and run anyway.
In an interesting twist, the team at Pale Moon have created an early-2017 Unified XUL Platform (UXP) hard fork of the Mozilla Code Repository as a starting point for further development and a potential base for Pale Moon in the future. As part of this process, they are also looking to develop a new browser, codenamed ‘Basilisk’, as a demonstration application for the aforementioned.
Waterfox was initially created back in 2011 and the code is currently based on version 53 of Firefox. It fully supports XUL, XPCOM and NPAPI plugins. While this offers a very promising solution, it is still a one-man operation, so maintaining XUL-compatible code might be a challenge as Firefox’s development continues to diverge.
Seamonkey also deserves an honorable mention. While not a browser in the true sense, Seamonkey is a community-driven internet suite and a continuation of the earlier ‘Mozilla Application Suite’ (by Mozilla). Seamonkey includes a browser, an email client and a news client, and retains compatibility with many existing Firefox and Thunderbird addons.
Firefox does not convert every major release into an ESR release. The current version of Firefox ESR is 52. Each ESR branch is supported for a period of one year and Firefox 52 ESR will cease receiving updates in June 2018. The prior ESR version of Firefox was Firefox 45 ESR, which has been end-of-life as of June 2017. The next version of ESR will be based on Firefox 59’s codebase (tentatively scheduled for March 2018), but it is important to understand that Firefox 59 will no longer support legacy addons.
Because the current version of Firefox ESR is 52, it indicates that it uses the same codebase and feature set as the main version of Firefox 52, just with security-only updates being applied to it on an ongoing basis. In short, this means that Firefox ESR 52 will be the very last official Firefox version to support legacy addons, and it will do so up until June 2018 (when support for that branch ends).
Firefox ESR will normally install over your existing version without any issues, assuming you pick the matching 32bit or 64bit version and point the installer to the same directory. However, there may be some Firefox profile incompatibility issues when the version is downgraded from 55+ to 54 or below (including Firefox ESR 52). This is due to some profile changes that Firefox 55 introduced, so the downgrade process may entail resetting your profile, via the profile refresh mechanism, or restoring it from an earlier backup (if you kept one).
Have Mozilla made the right decision?
This is something that only time will tell, but Mozilla are preparing to weather the storm on the horizon. The company is steadfast in its determination to deliver Project Quantum according to their planned roadmap and without delay. Contrary to Mozilla’s mission statement about delivering a browser for the users, in reality, the users are ultimately powerless to control their direction. Software development has, and will always be, a tug of war between two opposing viewpoints – the need for developers to innovate and drive the project forward, and the desire of many users to maintain the status quo.