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.
Thanks!
I’ve had to downgrade to Firefox v46 and use the selenium driver not gecko in order to get my tests to work correctly. Chrome on the other hand works perfectly.
Joseph, your comment doesn’t contain anything which is related to my blog post. If you have problems with geckodriver then seek for help, or file at least an issue at https://github.com/mozilla/geckodriver/issues with all the details as requested. Thanks.
“please let us know about misbehavior when using Firefox 58”
I don’t have the mandate or budget to re-engineer the selenium drivers at this time so it was cheaper to downgrade firefox.
I discovered the selenium docker images and they are much more convenient for my needs. the selenium chrome docker works perfectly for me, and the older version 45 of firefox also works well.
I am successfully using docker image selenium/standard-selenium-chrome latest version and docker image selenium/standalone-firefox:2.53.0
Using Firefox 57.02 with the latest selenium-firefox-debug docker image firefox was unable to find elements on a page, unable to find a form element.
Meanwhile the exact same test succeeds using selenium-chrome-debug
the exact same test succeeds using selenium/standalone-firefox:2.53.0 contains firefox version 45
in my behat.yml I had to specify version 45
but when testing the latest selenium image selenium/standalone-firefox containing firefox 57.02 (asuming similar to firefox 58?) I tried with the recommended version * and also version 57 to no avail.
If you look on selenium docker page, they note that all firefox builds have failed since version 45. Newer versions of firefox are not passing seleniums own build tests.
Something is obviously wrong.
see the selenium docker page. The only firefox version I got working was the one that passes selenium tests.
https://hub.docker.com/r/selenium/standalone-firefox-debug/builds/
The last standalone-firefox-debug build that says ‘Success’ is the one that contains firefox version 45.
This is not just affecting me, it is affecting the entire selenium planet globally.
I’m not sure if it is a miscommunication between the mozilla folks with the selenium docker folks , or if it is just due to mozilla changes that they are unable to refactor.
I did my own non-docker build with firefox version 46 and I was able to get that working with selenium. installed the dependencies etc.
I’ve read a lot on the web, seems like newer versions of firefox are reported as problematic and the common recommendation is just to use chrome instead. I prefer to use both , so I found a working solution this is what I am sharing. The easiest solution to keep your tests working is to use the selenium docker image that works
selenium/standalone-firefox:2.53.0
Just to clarify here, I’m one of the maintainers of geckodriver, and nothing what you have written in the last comment is known to us. So I strongly advise you to check with the folks maintaining the docker images what’s wrong. I just had a look at the test failures you were mentioning. All of them are reporting errors because of a busted configuration of the docker image or test job. You can see the failure message here: https://hub.docker.com/r/selenium/standalone-firefox-debug/builds/b24awar99ajeurqzjycgayd/.
By using docker images you always have to rely on the quality of the images others are producing. To really check the quality of our driver for Firefox you also try it locally without any docker environment. And then as best with a binding of Selenium directly, and not any kind of additional wrapper harness. Each additional level will cause risks and possibilities of failures. This is what we have seen a lot over the last couple of months, because those extra layers did not correctly implement the commands, or haven’t those correctly updated. Even plain Selenium still suffers with the WebDriver spec in some areas.
Beside that I want to mention that using Firefox 46, which is an unsupported version for a very long time, is affected for a lot of security issues, which have been fixed in more recent releases.
I would suggest that you take advantage of the gorgeous community for Selenium and Mozilla by using their support forums, IRC channels, or issue trackers to get problems solved.
The latest selenium docker images use selenium 3.8.1
which version of selenium do you recommend with firefox v58 ? also, any links to an example set of recommended dependency versions?
Maybe someone can light a fire underneith the selenium docker maintainers keyboards.
If the latest chrome works with docker I don’t see why firefox would have a problem.
Docker is the way to go, although it is not necessary and I’ve done it without.
Helpful link to example setup documentation would be appreciated thanks.
Using the latest release of Selenium should always be a good idea. It will ensure that more features are supported related to the webdriver specification. In regards of your comment about chromedriver, it is not using the webdriver implementation by default. As such this might be the reason why all is working fine. But well, I’m not a developer of that driver, and don’t know the details in how it plays with Selenium.
A simple Python test using Selenium to open a web page can be still found at https://www.hskupin.info/2017/01/23/using-selenium-and-webdriver-to-interact-with-insecure-ssl-pages-in-firefox/. You could try this with your expected web page and see if it works. It’s easy to setup with virtualenv for Python, and by installing the Selenium bindings from PyPI:
pip install selenium. Otherwise everything else documentation related to geckodriver can be found at https://github.com/mozilla/geckodriver/How would I go about reversing this change in a current version of firefox? Even if it means building firefox to take out this interactability check for send_keys. Be as specific as possible – files and lines of code to look at. Has the legacy behavior actually been removed as of now? If so, could you reference it.
Are there any specific problems you are facing with the interactability checks? I would rather see those solved, as seeing you falling back to the legacy behavior. The latter is still in and can be used by following the steps as described at: https://firefox-source-docs.mozilla.org/testing/geckodriver/geckodriver/Capabilities.html#moz-webdriverclick
I have come across that solution. You have mentioned it to others. A concrete example of it being implemented in Python could go a long way for me. I am a novice when it comes to Mozilla/Firefox/geckodriver. However, I wanted to avoid utilizing this solution because it seems to be something that will only stay around temporarily. I specifically want to be able to upload a file to an input that is not visible by sending it a file path to a file that is stored locally on a machine. It seems this is out of the scope of the web driver specification based on my reading of other people running into this situation. May I ask why this specification is followed so closely in this particular instance?
Hidden file input elements were indeed a problem for a while. As agreed at TPAC last year we were going to relax interactability checks for those elements. See also the geckodriver 0.24 release notes: https://github.com/mozilla/geckodriver/releases/tag/v0.24.0. I assume that you are using a slightly older version of Firefox. In such a case you should upgrade to Firefox 65.0, and it has to work without by default.
Based on what you’ve told me:
I changed nothing to my code but updated firefox to the latest stable build (65.0.1), and replaced geckodriver 0.23.0 with 0.24.0. This has resulted in no effect and the file was not uploaded. If I were to do this with firefox 57 and use gecko 0.23.0 it will work. When trying to use an old version of firefox, I can’t get the updates to shut off. Toggling booleans and changing settings seems futile to switch off auto updating. Based on what 0.24.0 describes, I shouldn’t have to change anything because strictFileInteractability is false by default – like you said (if I am understanding correctly). So I am not certain what I am missing here. I might have to resort to that legacy behavior for the time being.
If there is still a problem please file an issue at https://github.com/mozilla/geckodriver/issues, and especially attach the trace log for such a test so that we can investigate it. Thanks!
Useful reference for anyone else that stumbles upon these comments in the future:
https://www.w3.org/2018/10/26-webdriver-minutes.html#item06
https://github.com/w3c/webdriver/issues/1230
https://github.com/w3c/webdriver/issues/1355
After some repeated attempts of trying to utilize 0.24.0 geckodriver and 65.0.1 firefox, I finally was able to get them to work with what I was doing. I ended up having to change the behavior of my driver and how it waited on the site. You have been immensely helpful. I appreciate what you’re doing. Keep up the good work!