W3C WebDriver protocol support

[shs96c]

The next major release of Selenium (version 4) will see a major change in the wire protocol: language bindings will move from supporting the original wire protocol to the new W3C webdriver protocol. Specifically, we expect the .Net, Ruby, Python, and JS bindings to all only support the webdriver protocol. It is likely that additional effort will need to be taken by Java developers to continue using the original wire protocol.

Selenoid needs to support the matching algorithm outlined in the spec, as well as ensuring that metadata is passed through to downstream nodes.

Our current working estimate is that Selenium 4 will ship before October, 2018, though (as with all OSS) this is only our own estimate.

[vania-pooh]

@shs96c sure, we are following the news about W3C Selenium standard adoption. Right now we already support working directly with latest Geckodriver releases as well as alwaysMatch stuff. In this issue let's review the spec again and make core protocol changes are supported. Btw, when do you expect to have the spec finally accepted as recommendation?

[shs96c]

The spec should become a recommendation on the 31st May.

Once the session is established, something like selenoid shouldn't need many changes. Things that differ are:

• The matching of capabilities when creating a session. It sounds like you look at alwaysMatch, but a quick scan of the source suggests your not merging this with firstMatch
• desiredCapabilities is going away in the w3c spec, but it doesn't look like you're that dependent on them.
• It doesn't look like there's validation of capability names going on for W3CCaps, which is mandated by the spec. Technically an endpoint node is the only one that needs to care, but it reduces resource consumption if intermediate nodes do this processing.
• I guess you've already noticed that the JSON Wire Protocol and the W3C protocol return the session id in different places in the return value for New Session.

Feel free to hop on the #selenium IRC channel on Freenode or our Slack channel (which is mirrored to IRC) if you'd like clarification on any of the areas or to talk about implementation strategies.

[vania-pooh]

@shs96c ok, thanks.

[vania-pooh]

Also need to correctly process capabilities key.

[vania-pooh]

Ok, we decided to just ignore firstMatch key as nobody seems to be really using it. Some client-side libraries are just always sending an empty array there. The only thing we have to fix is - completely drop vendor-specific selenoid:options key before actually proxying request to upstream webdriver. This will be fixed in #771. Closing this one.

[shs96c]

The java bindings will fill firstMatch if necessary, and some of the other language bindings prefer using firstMatch to alwaysMatch. I’d consider reopening this.

The algorithm for converting the New Session payload is incredibly simple: just merge alwaysMatch into every firstMatch and throw an error if there are duplicate keys. Then just iterate over the generated list and find the first one your hub supports.

[vania-pooh]

@shs96c ok, let's reopen and see what could be done with it.