Nice! This looks promising. Looks like some of the Travis builds are failing. I don't have time to look until the week though.

I'm curious what changed with the JSON format for Element refs. Looks like it returns a list of Element IDs now? in which cases would it return multiple IDs?

Actually the changes run much deeper than I initially had thought. It seems that Selenium running in standalone accepts much of the legacy wire protocol, while running as a hub it does not. I will continue to update things as necessary, to restore functionality when run against hub.

Ok have implemented enough of the WebDriver spec that it passes the test suites here at work Its a much heavier change than the initial one. Unfortunately it seems that this is incompatible with selenium standalone :| Will need to come up with a way to support both.

I just tried chromedriver, it fails quite quickly with
"message":"unknown error: 'value' must be a list.

I'll see if I can reconciliate the two at least, to have both browser drivers functional if possible.

My concern here is that I currently have no way to easily test if these changes work for both 3.x and 2.x. Do you have a sample test script I can run to do a simple smoke test?

This lack of rigorous testing has been an issue with this project from the start. I think the ideal plan of attack here would be:

1. Create a command line utility to download and install Selenium standalone versions. In the Javascript world, they have a webdriver-manager package which does something similar. We could leverage that tool, but it seems awkward having to use a non-Haskell utility to test something within the Haskell ecosystem. So I think ideally we should build it. This will not only make the developer experience better, but will also make it easier to setup automated integration tests.
2. Run an integration test suite against each version of selenium-standalone, using the command line utility to install/uninstall.
3. Hook all this stuff up to travis CI so that we can test all possible combinations automatically

I think having robust Selenium 3.x support with backwards compatibility with Selenium 2.x is extremely critical to the longevity of this project. As it currently stands, I can commit a few hours a week towards this initiative. I would even say we should create a Slack workspace to help coordinate.

I welcome any other thoughts or suggestions.

+1, this would be great

We've switched to python selenium due to various issues with haskell and selenium, so we might not be able to provide further testing or update this PR.

I'd like to help out a bit, here are some thoughts.

Create a command line utility to download and install Selenium standalone versions. ...

I disagree that this is a responsibility of this package. This is straying into 'package-manager' territory and feels (to me) fraught with issues.

The key problem is ensuring that the user has a compatible version, or knows how to retrieve one?

Perhaps documentation is the key with this, as we don't want to be be dismissive and say "use your favourite package manager". We want to provide guidance so users understand we rely on a third-party managed tool. Here are the versions we support, here are some links, here is webdriver-manager if you like, here are some SHA values to be sure... etc.

• Run an integration test suite against each version of selenium-standalone, using the command line utility to install/uninstall.
• Hook all this stuff up to travis CI so that we can test all possible combinations automatically.

Tests are delicious and nutritious! For this I would configure TravisCI to explicitly download a version of selenium-standalone, check the SHA, and the tests would explicitly start the required version. Make Travis do the work instead of reimplementing what it already can do for us. It's explicit and the config is stored in source control. :)

That would let us pull in a headless browser to test against ? I would imagine we can script up some of this so that people wanting to contribute aren't left hanging?

I think having robust Selenium 3.x support with backwards compatibility with Selenium 2.x is extremely critical to the longevity of this project.

May I ask why? I don't know the Selenium ecosystem well enough to have an informed opinion.

I've merged #153 which provides some backwards compatibility with the old Element format. Can you merge that change into this PR @cfraz89 ?

I shall see if I can get time to do a little improvement on this, hopefully I can get it working for modern browsers, and then that'll be grand.

Yes, this is I think the only outstanding thing in the whole headless testing infrastructure, so that makes it imho quite important. I historically have used selenium-standalone so shall see whether I need to use a different launch option or whether it'd work with geckodriver, etc.

Yes, I've also verified that running as a hub and running as a node also will make existing scripts with little change (e.g. Word to Float, sizes to Rect) work with this patch. Running standalone gives errors that explain that the session ID doesn't exist.

I'm going to close this now, since we're almost ready to release a new version that will support the recent WebDriver spec. This PR was helpful for getting started on this effort, so thanks!