Selenium 3 support

[psivesely]

Currently we are pinning Selenium 2.53.6 (and consequently Firefox 46.0.1) in order to avoid migrating to Selenium 3, which depends on https://github.com/mozilla/geckodriver. Since Geckodriver is not in the Ubuntu repositories, https://www.npmjs.com/package/geckodriver might be the easiest way to install it--since that way we will not have to manage updating the version number as we would if we installed from the tarballs https://github.com/mozilla/geckodriver/releases.

[psivesely]

So, geckodriver is shipped as a single Rust binary. It would be easy enough to download the release tarball from Github and extract it to /usr/local/bin/geckodriver (pinning the SHA sum in Ansible) with Ansible, and I've tested this works on my machine w/ FF stable + Selenium stable. Using npm doesn't give us an advantage really in this sense--either way we'll want to bump versions manually after testing to ensure compatibility between Selenium and Geckodriver.

[tkell]

Hello @fowlslegs, I was thinking about taking a shot at this, unless you're close to a PR?

If not, it seems like we'd need to:

• Get a stable Github URL for geckodriver, and make an Ansible task to extract it to the location as you describe.
• Update the versions for Selenium and Firefox.
• Make sure it all works.

[redshiftzero]

Dang, sorry, I worked on this in the afternoon. I have a branch here add-selenium-3-support doing this but I had to do some slightly annoying stuff to get the functional tests to pass using geckodriver (see commit here). Feel free to give it a shot and submit a PR to add a commit to that branch, I'll pull in your commits if you find better ways to do anything 💯

[psivesely]

You don't need to check if the tarball has already been downloaded or extracted to /usr/local/bin because the get_url and unarchive Ansible modules implicitly do that for you (i.e., they are idempotent). Of course, the implementation of the idempotence isn't perfect. E.g., if the version of geckodriver is changed and you re-provision neither your code, nor the unarchive module, will install the new version. To get around this try calling geckodriver --version with failed_when: false, register the result, and re-installing if 'version not in result.stdout' (where version is the version variable--see below).

Another thing is instead of hardcoding v0.14.0 in the tasklist file, you'll want to assign it a {{ variable }} the role defaults.

Will try to take a look at the tests stuff Monday.

[heartsucker]

I think you mean changed_when: false since it's still possible for the task to fail. Am 06.02.2017 00:51 schrieb "Noah Vesely" <[email protected]>:

…

You don't need to check if the tarball has already been downloaded or extracted to /usr/local/bin because the get_url and unarchive Ansible modules implicitly do that for you (i.e., they are idempotent). Of course, the implementation of the idempotence isn't perfect. E.g., if the version of geckodriver is changed and you re-provision neither your code, nor the unarchive module, will install the new version. To get around this try calling geckodriver --version with failed_when: false, register the result, and re-installing if 'version not in result.stdout' (where version is the version variable--see below). Another thing is instead of hardcoding v0.14.0 in the tasklist file, you'll want to assign it a {{ variable }} the role defaults. Will try to take a look at the tests stuff Monday. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1502 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD0DAJkgINQ1WXTWkG8DNFpvNMlEyHb9ks5rZmBkgaJpZM4LRHqP> .

[psivesely]

Actually, you want changed_when: false and failed_when: false. Though the latter is more important because if geckodriver is not present, we don't want the playbook to fail; we just want to register that it's not there so we can install it in the next task. changed_when: false is not necessary, but good practice because command: geckodriver --version is idempotent, but the command module is (for obvious reasons) not able to automatically know when it's affecting changes or not.

[tkell]

So there are the Ansible tweaks mentioned above.

@redshiftzero, are the self.wait_for calls the annoying part? (I could not get away from those in my past life as an Angular dev)

[psivesely]

@tkell Please read #1569. We might want to let this branch chill for a while until tbselenium supports selenium>=3.

[psivesely]

@fowlslegs, in case it helps with your internal scheduling, we need to wait until the release of the ESR 52 based Tor Browsers to land Selenium 3 support.

Tor Browser 6.X versions are based on ESR 45, which is not supported by geckodriver.

The expected date for ESR52 based Tor Browser is June 13: https://lists.torproject.org/pipermail/tbb-dev/2017-February/000472.html.

-- webfp/tor-browser-selenium#58 (comment)

[redshiftzero]

closed by #4347