To understand why existing Selenium tests will no longer work with Firefox 48 and beyond, we need to first see what changed were deployed by Mozilla starting with this version.
What has changed starting with Firefox 48?
Firefox 48 is already a stable release starting with 2nd of August, 2016 and is a major release in the sense that makes add-on signing mandatory on Stable and Beta versions and introduces multi-process functionality to a first batch of users.
Going a bit more in details:
- Firefox extension signing is enforced on Stable and Beta versions of Firefox only. Users are no longer able to disable this requirement. Developer, Nightly and ESR builds are provided that still ship with the functionality.
- It seems that 1% of the Firefox users that do not run any add-ons have the new multi-process architecture enabled for them, a feature named Electrolysis (e10s).
- Bad news for users running on older versions of Mac OS, OSX 10.6, 10.7 and 10.8 to be more specifically. Support for this Mac OS versions ends. Firefox will basically still continue to function on these platforms, but they will no longer receive new features or security updates.
Why the older Selenium FirefoxDriver() no longer works?
The legacy driver is implemented by the Selenium team as a Firefox extension. This extension is installed in the profile used by the driver when WebDriver launches Firefox.
The new features introduced in Firefox 48 are responsible for this.
Firstly, it’s the Electrolysis one because this feature changes the way extensions have to deal with the browser.
Secondly, and the most important one, is the fact that the add-on now needs signing by Mozilla before the browser allows them to load. It seems that the WebDriver browser extensions represented several valid security concerns for the Firefox browser, and as such, will not be signed by the Mozilla’s security team. This causes the extension nonfunctional because Selenium can no longer communicate with Firefox.
To overcome this, Mozilla took ownership of the Selenium testing for it’s browser using Selenium. The Marionette based solution is being developed and maintained by Mozilla and represents a commitment from their part that it will continue to work with future versions as well (or at least we can hope).
The mechanism used to drive the browser is now part of Firefox itself, it’s built in the browser, therefore the reason why Mozilla is maintaining it. The Geckodriver executable provided by them acts as a translator to take the HTTP calls from WebDriver to use a Marionette communication protocol over TCP that the browser understands natively.
The good part is that the users using Selenium don’t need to care about the specifics, it will work using the same code that worked before (with a ‘but’ following).
But (there’s always one), the bad part (for now at least) is, as mentioned on their Geckodriver open-source page, Marionette and Geckodriver are not feature complete yet. This means that it does not yet offer full conformance with the WebDriver standard or complete compatibility with Selenium.
However, and I consider this extremely important, our duty as Open-Source users, is to help with the development process even in the slightest way like submitting issues to the Github project.
Join me in Part 2 where I get more into the details.