End of support for Selenium IDE in Firefox 55+. What can you do about it?

End of support for Selenium IDE in Firefox version 55 and newer (image credit: Freepik)

Mozilla’s decision to cease the support for Selenium IDE in Firefox 55 has drawn the attention of the testing community to a long-standing problem. We’ve all known for years that old-school record-playback tools underdeliver in the way of usefulness. Thanks to Mozilla, this has become more obvious.

Don’t get me wrong, having the UI testing functionality of Selenium IDE in Firefox was super-useful. Selenium IDE certainly deserves credit for doing exactly what it promises. It’s lightweight, it automates UI tests by recording manual testing sessions, and it has been the official Selenium recorder for Firefox since forever.

Built in 2006, it has long become the first tool that comes to mind when someone mentions record-playback UI testing. Maybe it’s due to this long history that the news of Firefox dropping Selenium IDE feels so unexpected.

So what is the reason for discontinuing the support for Selenium IDE in Firefox? There are two of them, actually.

Reason 1. Having ditched the .xpi format used in Selenium IDE, Firefox will move to WebExtensions

To keep moving forward, you sometimes have to leave things behind. Cheesy as this may sound, it’s painfully true for mainstream technology. In case with a technology as mainstream as the world’s 3rd most popular browser, leaving things behind often means leaving developers out it the cold.

Last November, Mozilla announced its plans to fully transfer Firefox extensions development to the WebExtension API. The reasoning behind this move effectively comes down to two points:

• The WebExtension format is decoupled from the browser, which accounts for easier development. In particular, developers will be able to produce extensions without in-depth knowledge of the Firefox internals.
• WebExtension promises better cross-browser functionality. In theory, better interoperability with Chrome and Edge may increase the number of developers willing to build new plugins to Firefox.

While these may sound great, there is an unpleasant side effect. Moving to WebExtensions means that all .xpi-based extensions lose compatibility with Mozilla’s browser starting from version 55. Being an .xpi-based Firefox extension, Selenium IDE would have to be rebuilt to retain compatibility with the browser. This brings us to Reason #2.

Reason 2. Developers show no interest in maintaining Selenium IDE in Firefox

Okay, the support of Selenium IDE in Firefox is a matter of rewriting the plugin, but how can this be a problem? Isn’t there a huge developer community behind Selenium? Sadly, everything is not that simple. While there certainly are many contributors backing up Selenium WebDriver, the situation is different for Selenium IDE.

As it turns out, the IDE has been lacking developer support for a long time. Over the past couple of years, there’s been but a handful of contributions, with only 11 regular committers. In 2016, there actually was just one developer filing commits for Selenium IDE:

In a way, the situation with Selenium IDE in Firefox proves that even great projects can become semi-abandoned at a certain point. Still, there were quite a few factors that made this state of affairs predictable.

The somewhat bitter truth about Selenium IDE is that it has little to offer for real-life testing. It’s a great tool for learning or building small garage projects, but it can’t keep up with the pace of commercial applications development.

While the IDE’s record-playback solution gives you a head start, its autogenerated scripts are too messy to maintain en masse. As a result, testers mostly fall back on handwriting Selenium code from scratch, or doing UI testing manually. Needless to say there’s little incentive to support an open-source project if developers don’t use it in their work.

What the future holds in store for Selenium IDE?

There have been attempts to resuscitate the community surrounding the IDE. Discussions are taking place in the Selenium developers’ mailing list and Slack channel, with new developers encouraged to join.

If these efforts will prove to be a success, chances are we’ll see a new WebExtension-friendly version of Selenium IDE in Firefox. Who knows, maybe it will fill in the gaps left in the original version… But today, we’re months (or even years) away from this.

In the meantime, people are looking for a reliable solution for visual UI testing can look at Selenium IDE alternatives. One of such alternatives is our very own solution Screenster. Let’s see what makes it different from other record-playback platforms.

What makes Screenster better than the Selenium IDE + Firefox combo?

If you’re looking for a short answer, Screenster offers a solution that works for real-life testing. It moves from “record-playback” to automated “record-playback-verification”, it supports CI, and it uses the concept of Visual Baselines for UI testing testing. Below, you’ll find a brief overview of the features that make Screenster a truly unique solution.

Visual Baselines with automatic verification of everything on a page

Just like Selenium IDE, Screenster provides you with a WebDriver-based record-playback tool that automates manual UI testing. Still, there a difference in how Screenster handles record-playback.

While recording a test, the platform generates Visual Baselines complete with page screenshots, DOM snapshots, and lists of locators for every UI element. The platform automatically verifies every on-page element during regression testing, and it analyzes the underlying structure of the UI, not just screenshots.

Pixel-perfect where it matters

When it comes to screenshot comparison, however, Screenster detects all layout shifts, even if we’re talking about one-pixel difference from the baseline. At the same time, the platform is able to recognize and sort out the “visual noise” caused by rendering. As a result, you get a precise screenshot comparison functionality without false positives.

Codeless test editing

Dealing with autogenerated code is unproductive and unpleasant, which is why you won’t have to do it with Screenster. Instead of generating Selenium scripts, Screenster saves UI tests as series of editable codeless steps that you can access and manage via a dashboard.

Working with the Screenster test suites is so simple anyone can pick up the basic functionality of Screenster in under 15 minutes. In a nutshell, Screenster is one of the few codeless platforms that deliver on the promise of making test automation fully accessible for manual testers and non-technical users.

Automatic timeouts and locators

Timeouts have always been notoriously difficult to deal with, so we thought it would be great to fully automate timeouts handling. Instead of making you set explicit or implicit timeouts manually, the Screenster automatically determines the optimal waiting time for UI events.

The same thing goes for locators. While hand-coded tests depend on a tester’s ability to determine an optimal selenium locators strategy, Screenster handles locators for you by building a complete list of locators for every UI element. If a locator it’s currently using gets broken by a UI change, the platform picks another one from the list. With everything happening under the hood, locators and timeouts become non-issues.

Dynamic regions

Yet another automated functionality is the smart handling of dynamic regions. Normally, a tester would have to hand-code workarounds whenever working with things like ad banners, timestamps, or, say, gravatars. When working with Screenster, these are dealt with via a couple of mouse clicks.

The platform is able to identify dynamic regions automatically, while recording and optimizing a test. If there are dynamic regions on a page, Screenster will offer the user to automatically ignore them during further test runs. It also possible to handle dynamic regions manually, by clicking on them.

Codeless test automation done right

If you’re looking for an open source project to take on, restoring the support for Selenium IDE in Firefox will be much appreciated. Still, Mozilla’s decision to move from .xpi isn’t the only driving force between the downfall of the famed IDE. Knowing this, what the testing community might actually need is a wider functional scope for visual testing projects.

As far as Selenium IDE competitors are concerned, Screenster is, naturally, not the only game in town. That said, the platform offers a whole bunch of unique features that provide actual practical value. You can try the online version of Screenster for free and see how it works for your website or web app. I’m sure you’ll appreciate the simplicity.