Support W3C WebDriver protocol

[michallepicki]

Add support for the W3C WebDriver protocol.

Currently for Chromedriver and Selenium Wallaby uses endpoints and capabilities as specified in Selenium WebDriver JsonWire Protocol.

The "new" W3C WebDriver protocol is supported by all major browser drivers (Chrome, Firefox, Edge, Appium) and for some browser drivers, it is the only supported one (Safari - see Overview). AFAIK Selenium 4 tooling (which is due to a release soon, there are already release candidate versions) - so Selenium Standalone and Hub servers for managing WebDriver sessions, and Selenium-supported WebDriver client libraries - will support only the W3C WebDriver protocol.

I've looked into upgrading Wallaby to use W3C protocol and have a "work in progress" branch here. You can see the current diff here. 1 selenium test and 4 chromedriver tests are currently failing (chromedriver logging, and WebDriver "send_keys").

After we get all tests passing, my current plan is to split W3C WebDriverClient into a separate module, and allow the user to pass an option to use it.

Another area that will need to be taken care of, is Selenium Atoms. These are javascript replacements for commands that were not included in W3C spec, namely GET :element/displayed and GET :element/text. Firefox documentation has a writeup on generating them here. Because sending these scripts to drivers that do support these commands may not make sense, we could also make their usage configurable.

[michallepicki]

We got all selenium integration tests to pass on our branch, updated diff here. Capabilities format seems to have changed but we're still researching if passing capabilities through firstMatch array is required on all platforms.

Currently working on adding the element/displayed javascript atom that would be optionally used in Selenium when a flag is set in :wallaby application configuration.

[michallepicki]

Update: I simplified capabilities format and added an option to use element/displayed atom. We're testing things on a few platforms on Browserstack:

• window or iframe handling seems janky in Safari and in newer Appium on Android, in any case my PayPal payment flow tests are not passing right now. Investigating
• I still need to fix fetching logs from Chrome
• The element/displayed atom makes running tests much slower on Edge 18 and Safari 12 (I wish they just kept the endpoint like other browsers). Looking into updating the script to a newer version from selenium codebase, or maybe switching to a version from webdriverio
• To have both protocols simultaneously, I added a :use_w3c boolean field to Wallaby.Session. I did that to be able to switch back to old protocol on per-session/test basis (having Application.put_env config was not good enough for me). Not sure if this is the way to go, as it looks driver-specific. Instead I could have made separete modules for W3CSelenium and W3CChrome but this also looks wrong. Maybe we can have a options keyword list field in Wallaby.Session struct? @keathley @mhanberg

Any way, here's the diff so far and if you're adventurous and want to try it out, use

{:wallaby, github: "revzilla/wallaby", ref: "da7e93ab29be94f2ccb6072101115454c07c2683"}

and pass use_w3c: true to start_session options

[michallepicki]

Update: I'm not working much with Wallaby and/or integration testing anymore, so I probably won't be completing this work, but I'm happy to provide any help I can and insight I gained from dealing with the W3C WebDriver protocol.

[mpinkston]

@michallepicki @mhanberg @aaronrenner Hello! I'm thinking about taking a crack at this ticket (hoping to use Wallaby in conjunction with AWS DeviceFarm) and had a question about the existing web_driver_client dependency; though the library itself seems designed for handling the abstraction between JWP and W3C, it currently only appears to be used in the ChromeDriver ReadinessChecker. Moving forward, are you hoping to handle these abstractions entirely in Wallaby or perhaps leverage this library a little more fully?

[michallepicki]

Hi! I found it a bit tricky to provide a unified abstraction over both versions, but there is overlap. There are commands removed, added, and some behave slightly differently. I personally would make sure to get both separate implementations right first and then look from wallaby side to find common usages. Maybe @aaronrenner can speak a bit more about the state of web_driver_client?

[mpinkston]

That makes sense. I think I'll try something along the lines of defining behaviours for each protocol and using adapters to implement them which can then make web_driver_client an optional dependency

[mpinkston]

so, I hacked in partial support awhile ago but haven't kept the branch up to date or anything.. but, if anyone's interested, here it is: https://github.com/TableCheck-Labs/wallaby/tree/hydra-devicefarm

I might give it another go if I can find time.