Changes to Selenium IDE Plugin System

Plugins for Selenium IDE were an awesome idea. They allowed plugin authors to execute any code they wanted. However, with great power also came great risk of breakage. A practical problem that arose is that when a plugin broke down, it could take Selenium IDE down with it. I am NOT saying that plugin authors are writing bad code. More often than not, if someone has managed to successfully create a useful plugin even after the sparse documentation available, they are good at what they do. When Mozilla switched to the rapid release cycle of six weeks, most plugin authors find it difficult to find time to react to any breaking changes. The recent changes even broke Selenium IDE. Whatever the reason maybe, the end result is that Selenium IDE can suffer.

I wanted to try and improve this situation. While automatically fixing the plugins would have been wonderful, the solution for that has still not reached me. So with Selenium IDE v2.1.0, I have released the first step towards a better plugin system for Selenium IDE. This post will help you to understand the changes and give you a glimpse of the things under the hood and also be prepared for potentially unpleasant surprises.

The Plugins Tab in Options Dialog

This is the most visible change in Selenium IDE v2.1.0. The plugins tab has been enhanced. There are two main changes, one which can be applied to each individual plugins and the other that affects the plugin system as a whole.

The first change is that the code provided by a plugin can now be disabled using a checkbox. When you select a plugin from the list on the left hand side, information about the plugin is shown on the right hand side. Below the information, you will now find a checkbox “Disable code provided by this plugin” which does this.

The other change is that Selenium IDE can now automatically disable plugin code when an error occurs in a plugin. Due to the flexibility provided to the plugins, not all types of errors can be caught, but it is a start. This option applies to the plugin system as a whole and therefore to all plugins. The first checkbox labled “Automatically disable plugin provided code on plugin errors” tells Selenium IDE if you want to disable plugins on errors. The second checkbox labled “Disabling plugin should completely disable the plugin in Firefox” controls if the plugin is also disabled in Firefox Addons. This disables the plugin completely. See the Under the Hood section for more explaination on this.

See the highlighted areas of the screen shot to get a clear idea of where these check boxes are located.

Another change is that if a plugin had thrown an error, it is now recorded and the plugins tab will provide information about it. While the fact that the plugin threw an error is stored, the actual error is only available until Selenium IDE is closed. The title of the plugin will change colour to highlight this. See the screen shot for an example.

Under the Hood

A plugin for Selenium IDE is an Addon for Firefox. Thanks to this, Firefox manages some portion of the functionality. The most visible being the installation and removal of the plugin. Firefox also manages the update process for the addon. Plugins that need to change the User Interface of Selenium IDE by providing new elements or removing or modifying existing ones, usually also use the Firefox technology XUL. This portion of the plugin is managed by Firefox as well. Along with this, the plugin can provide code to Selenium IDE to be executed at various points using the Selenium IDE plugin API. This leads to an interesting situation – part of the plugin is applied by Firefox and part by Selenium IDE.

Selenium IDE could easily control the code that was provded to it using the plugin API. But, due to the way the plugins were managed earlier, in case a plugin encountered an error, there was no way to determine which plugin it was. All code provided by all plugins was put in a shared pool. The information about which plugin contributed which code was lost. Now, this information is stored and used whenever needed. If more than one plugin throw an error, instead of getting a technical description for each error, a single dialog alerts you that there were errors in loading the plugins and specifies the plugins that were affected. The last error of each plugin is also shown in the plugins tab in the option dialog.

Once a plugin gives an error, most users would need to diable the plugin. So far, the only way was to disable or uninstall the plugin in Firefox. To reduce the action the user needs to take, I brought the ability to disable the plugin into Selenium IDE itself. Each individual plugin code can be disbled from within Selenium IDE itself with the checkbox provided for each plugin.

I could have stopped there, but I wanted to make things even easier for the users. At this point Selenium IDE knows that a plugin had an error, and it can also disable the plugin, why not do it automatically instead of focring the user to do this? So I also made it possible to disable the plugin code automatically whenever it produced an error. As I mentioned earlier, this is one part of the plugin, the other part needs to be disabled in Firefox itself. If the other part is not disabled, it may leave items in the user interface that do not function as expected as the code that provides the functionality was disabled. The two checkboxes at the top of the plugin tab in the options dialog control this behaviour. While I believe, most users should leave these two checked (the default behaviour), the power users or plugin developers who want complete control can turn it off.

Not all errors are caught. Only errors during the plugin load are caught and the plugin code is automatically disabled. Since a plugin can change anything it likes, not all errors can be caught, but I think this change should help in giving more control back to the users.

To make all this possible, the plugin system code has changed significantly. By default the automatic disabling is turned on. So if you find that your plugin provided functionality has stopped working, you can check in the plugins tab to see if it has been disabled. If you do not want Selenium IDE to ever diable a plugin automatically, uncheck the checkboxes in the plugin tab of the option dialog.

The Next Steps

While disabling the plugin code and disabling the plugin in Firefox on error is a good start. I found that it can be a bit confusing to use. I am planning to simplify it even further and always disable both the code submitted by the plugin as well as disable the plugin in Firefox. I still need to think some areas though, like how to handle plugin updates, i.e. if a plugin gives an error and is automatically disabled, should it be enabled automatically when a new version of the plugin is installed? How to wait for the asyncronous details about the plugins from Firefox? How to handle detecting updates? and so on. I would also like the plugin list itself to indicate if the plugin is enabled, disabled or has errors so that you can get a quick overview in a single glance.

So expect changes in the future versions and as usual, you, as users of Selenium IDE are collectively the most important stakeholders. Feel free to tell me what you think.

2 Responses to Changes to Selenium IDE Plugin System

I want to thank you for your time and efforts towards Selenium IDE. I have found a lot of value in your plug ins, especially DataDriven. In fact, I had a developer friend help me tweak it to allow nesting loops via naming each loop. This allowed me to make my .xml files discrete and easier to maintain.

I also found inspiration from your blog to write a few modest extensions that generate random data of various types and a date manager, both of which I consider to be common problems for testers.

Without your guidance, I doubt I would have been able to accomplish any of these tasks, so please accept my sincere appreciation for your tutelage.

Thank you very much for your kind words. I am happy to hear that you have made tweaks to existing plugins and written your own as well. Do consider making them open source so that other users can benefit. Btw, I did not write DataDriven.