When you are using Selenium and geckodriver to automate your tests in Firefox you might see a behavior change with Firefox 58 when using the commands
Element Click or
Element Send Keys. For both commands we have enabled the interactability checks by default now. That means that if such an operation has to be performed for any kind of element it will be checked first, if a click on it or sending keys to it would work from a normal user perspective at all. If not a not-interactable error will be thrown.
If you are asking now why this change was necessary, the answer is that we are more WebDriver specification conformant now.
While pushing this change out by default, we are aware of corner cases where we accidentally might throw such a not-interactability error, or falsely assume the element is interactable. If you are hitting such a condition it would be fantastic to let us know about it as best by filing an geckodriver issue with all the required information so that it is reproducible for us.
In case the problem causes issues for your test suites, but you totally want to use Firefox 58, you can use the capability moz:webdriverClick and turn off those checks. Simply set it to
False, and the former behavior will happen. But please note that this workaround will only work for Firefox 58, and maybe Firefox 59, because then the old and legacy behavior will be removed.
That’s why please let us know about misbehavior when using Firefox 58, so that we have enough time to get it fixed for Firefox 59, or even 58.
Interacting with insecure SSL pages (eg. self-signed) in an automated test written for Selenium is an important feature. Especially when tests are getting run against locally served test pages. Under those circumstances you might never get fully secured websites served to the browser instance under test. To still allow running your tests with a successful test result, Selenium can instruct the browser to ignore the validity check, which will simply browse to the specified site without bringing up the SSL error page.
Since the default driver for Firefox was switched in Selenium 3.0 to Marionette by default, this feature was broken for a while, unless you explicitly opted-out from using it. The reason is that Marionette, which is the automation driver for Mozilla’s Gecko engine, hasn’t implement it yet. But now with bug 1103196 fixed, the feature is available starting with the upcoming Firefox 52.0 release, which will soon be available as Beta build.
Given that a couple of people have problems to get it working correctly, I wrote a basic Selenium test for Firefox by using the Python’s unittest framework. I hope that it helps you to figure out the remaining issues. But please keep in mind that you need at least a Firefox 52.0 build.
Here the code:
from selenium import webdriver
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities
self.test_url = 'https://self-signed.badssl.com/'
capabilities = DesiredCapabilities.FIREFOX.copy()
self.driver = webdriver.Firefox(capabilities=capabilities,
if __name__ == '__main__':
By using DesiredCapabilities.FIREFOX the default capabilities for Firefox will be retrieved and used. Those will also include “marionette: True“, which is necessary to enable webdriver for Firefox in Selenium 3. If not present the old FirefoxDriver will be utilized.
To actually enable accepting insecure SSL pages, the capabilities have to be updated with “acceptInsecureCerts: True“, and then passed into the Firefox’s Webdriver constructor.
That’s all. So enjoy!
Update: The capability for acceptInsecureCerts is set automatically when DesiredCapabilities.FIREFOX is used.
Already two weeks ago, on November 3rd, the Selenium meetup #3 of the London Selenium user group has been taken place. Organized by Dave Hunt, we had 2.5h of interesting talks and discussions at the Google office in London.
The overall topic for this evening was how Mozilla is using Selenium and other tools to ensure the quality of their products. Therefore I have been asked to do a presentation about our client-side ui testing framework Mozmill. I was pleased to do so, because I thought that not that many people from that group have already seen how client tests for Firefox look like. Especially not when those get run directly from an extension in the crowd. But another reason also was our ongoing work for Mozmill itself and that we are thinking about using parts of Webdriver, which is a component of the upcoming Selenium 2.0 release. We already have contacts to the developers from Google, and I wanted to finally meet them and have a discussion to get an impression about the status of Webdriver.
I already arrived on Nov 2nd and had nearly one more day to finish up my slides and the extension itself. Everything went very well, even with a change in Minefield which has been broken the IPC-PIPE component my extension is relying on. By using an older Minefield build everything was ready a couple of hours before the meetup. The remaining time I mostly spent together with Simon Stewart, the leading person for the Webdriver development. He gave me a great insight in how native events are implemented, but also pointed out some open questions and still missing features. Personally I really missed the native events on OS X feature. I hope that it will find its way into Webdriver. But overall it looks great and once the focus issues are solved, we can try to investigate which parts we can re-use in Mozmill. Thanks Simon and Eran! Oh, and you are still welcome to do the same with our code. 🙂
Finally at 7pm the first chunk of people appeared and we had a welcome snack to create the first contacts. Half an hour later we have started with the first presentation in a really nice and already crowded lecture room. I believe about 50 interested people were attending the meetup – even with the underground strike happening in London this day. So Stephen Donner was heating-up everyone with technical details about how Selenium is used at Mozilla and how tests are getting run. Right after Simon Stewart entered the stage and while getting applause he talked about the current status of Selenium 2. After a following short break with more pizza and coke we continued with the second round of presenters. That means David Burns started to talk about how to use Selenium for client-side performance monitoring. He showed some interesting examples with Firebug’s YSlow add-on. Once he had finished his Q&A part, the stage was ready for myself. In the following 20 minutes people were able to see which topics Mozilla QA is working on, how strong we rely on and are proud of our community, and finally how the current state of the Mozmill Crowd extension is working. People were amazed of the demo, even it didn’t worked out that well because of a broken screen assignment between my MBP and the two big screens behind me. But that didn’t matter. I got lot of great feedback and questions afterward. Thanks everyone!
If you are interested in details of my talk, check my slideshare presentation: