Selenium 4, the latest version of Selenium, is currently available in the Alpha Version. There has been a lot of buzz around the release of Selenium 4 Alpha features, as it is packed with salient properties like relative locators, improved Selenium IDE, and improved Selenium Grid design that introduces a ‘fully distributed mode’ for automated Selenium testing. Apart from these visible changes, a major under-the-hood (or architectural) change is that WebDriver APIs in Selenium 4 follow the W3C (World Wide Web Consortium) in its implementation.
Here are some questions that might come to your mind regarding Selenium WebDriver APIs becoming W3C standardized in Selenium 4:
- What are the different Selenium 4 Alpha features?
- How does Selenium 4 becoming a W3C standard impact the Selenium community?
- What would be the significant advantages of the W3C WebDriver Protocol?
- Will this change impact the test scenarios that were working seamlessly on Selenium 3?
- Do we need to change the implementation tested on Selenium 3 to accommodate W3C standardized Selenium WebDriver APIs in Selenium 4?
This article would help answer these lingering questions as we deep dive into what W3C compliance in Selenium 4 means for the Selenium framework users.
Introduction: WebDriver in Selenium 4
As mentioned on the W3C website, WebDriver is a remote control interface that enables introspection and control of user agents. It provides a platform and language-neutral wire protocol so that our-of-process programs can remotely instruct web browsers’ behavior.
WebDriver provides a set of interfaces that aid in controlling the behavior of a user agent and discovering & manipulating the DOM elements on web pages (or documents). Apart from Selenium, WebDriver APIs are used in other automation tools like Appium, used mainly for mobile applications’ web testing.
Stable support for the W3C protocol was added in Selenium v3.8 through Selenium v3.11, as seen from W3C related patches in Selenium’s latest stable release (i.e., Selenium 3.141.59). The Selenium project had plans to migrate to an entirely new protocol – W3C and the same is happening in Selenium 4.
All the recent browsers (e.g., Chrome, Firefox, Safari, etc.), including Internet Explorer, are considered W3C compliant. With Selenium 4, you may no longer require to add ‘tweaks’ in the test script to make it work across different browsers, as everything (i.e., browsers & WebDriver APIs) will run in the W3C standard protocol.
With WebDriver becoming completely W3C standardized, you can now use it across different frameworks without compatibility issues.
Communication Between The WebDriver and Browser
In Selenium, the WebDriver offers a set of APIs that lets you discover and perform relevant operations (i.e., click, sendKeys, etc.) on the web elements present in the document (or page). A secure connection with the web browser is established using the corresponding ‘browser drivers.’ The browser is the end-point of execution.
As communication is happening between the web browser and Selenium WebDriver, both the parties should follow a set of rules (or protocol) that can be understood. With Selenium 4, the WebDriver and browser follow the same protocol (i.e., W3C), offering numerous advantages compared to the WebDriver used in versions before Selenium 4.
The JSON Wire Protocol
For Selenium versions earlier than Selenium 4, the JSON Wire Protocol was used for communicating with the web browser from the local end. As the Selenium Client libraries (i.e., Client) use the JSON protocol, and the web browser uses the W3C protocol, API encoding and decoding was involved in the entire process.
Starting with Selenium 4, the JSON Wire Protocol will no longer be supported. In case you still require backward compatibility and want to run the test scenarios using the old protocol, Selenium provides Java Bindings and Selenium Server for the same. With a focus on the W3C protocol, Java Bindings will continue to be backward compatible so that tests working on Selenium 3 do not break on Selenium 4.
WebDriver W3C Protocol in Selenium 4
‘WebDriver W3C’ is the newly introduced protocol in Selenium 4. It has received an endorsement from W3C (World Wide Web Consortium), the community which works on web standards development. W3C Working Draft and W3C Editor’s Draft are excellent resources to keep a tab on the progress of WebDriver W3C Protocol.
In Selenium 4, WebDriver W3C Protocol replaces the older JSON Wire protocol. It essentially means that you no longer need to encode and decode the API request using the W3C protocol, and the tests can directly communicate with the web browser. The information will not be transferred by sending and receiving HTTP requests and HTTP responses, respectively.
As seen from the architecture of WebDriver W3C Protocol, there is a direct information exchange between the client and server, without the need for the JSON Wire Protocol. As Selenium WebDriver and web browsers use the same protocol, automated Selenium testing will execute tests more consistently between different browsers. Flakiness in web automation can be considerably reduced if a standard protocol is used.
With WebDriver W3C Protocol in action, automation testers would no longer need to change the automation test scripts to work across different web browsers. Stability and Consistency in tests are the two significant advantages of WebDriver W3C protocol in Selenium 4.
Major Advantages of the WebDriver W3C Protocol
The introduction of WebDriver W3C protocol offers several advantages, including the following:
- The automated Selenium testing will run more consistently across browsers as the browsers, and Selenium WebDriver is using the same protocol.
- With WebDriver W3C Protocol, automated Selenium testing will be less flaky and more stable. Stability in tests is a major reason to shift to Selenium 4.
- Actions API in WebDriver W3C Protocol are richer in comparison to the one in JSON Wire Protocol. The Actions API is revamped to conform with the WebDriver Spec. Action APIs would now let you perform multi-touch actions, zoom-in, zoom-out, pressing two keys simultaneously, and more. For example, the Pinch-zoom sequence in W3C Protocol is represented by an action sequence consisting of three ticks and two-pointer devices of type-touch.
- Standardization of W3C opens up opportunities for promoting compatibility beyond WebDriver API implementations.
- Websites with W3C compliance help in reducing the maintenance efforts, as cleaner code results in improved readability.
However, the native support for Opera and PhantomJS is removed since the WebDriver implementations for these browsers are no longer under development. The fallback option for Opera users is the Chrome browser, as the Opera browser is based on Chromium. For PhantomJS, users should use Firefox or Chrome in the headless mode. W3C WebDriver Protocol is one of the prime reasons to upgrade to Selenium 4!
JSON Wire Protocol vs. WebDriver W3C Protocol
The JSON Wire Protocol is marginally different from the WebDriver W3C protocol. If you are using Selenium 3.141.59 – the latest stable Selenium version, you might already be using the new protocol.
The JSON Wire Protocol will permanently retire in Selenium 4. The Selenium Changelog is an excellent resource to keep track of the changes in Selenium WebDriver from a W3C compliance point of view.
The major difference is how a new session is created and how element interactions are performed using the Actions API. A look at the WebDriver W3C running document and now obsolete JSON Wire Protocol documentation shows that there are changes in error codes, data structures, and response status codes.
From a developer or automation tester’s perspective, in ideal scenarios, no changes are required in existing test scripts to make it run with the WebDriver W3C protocol.
Here is a brief list of the name changes across capabilities, proxy JSON Object, response status codes, error codes, etc. that come with W3C compliance in Selenium 4:
| JSON Wire Protocol | WebDriver W3C Protocol | Description |
|---|---|---|
| version | browserVersion | Browser version, which is a part of the browser capabilities. |
| platform | platformName | Platform or operating system the browser will be running on. |
| noproxy | noProxy | List the address for which the proxy should be bypassed when proxyType is set to manual. |
| UnknownCommand | unknown command | Requests could not be found, or the request was received using an HTTP method that is not supported by the mapped resource. |
| NoSuchFrame | no such frame | Desired frame to which a switch is performed is not found. |
| NoSuchElement | no such element | Web elements are not present on the page. |
| StaleElementReference | stale element reference | Command failed as the web element is no longer a part of the DOM. |
| ElementIsNotSelectable | element not selectable | Select operation cannot be performed on the desired web element. |
| JavaScriptError | javascript error | Error encountered when executing the JavaScript that is supplied by the user. |
| Timeout | timeout | Unable to complete the operation before the expiry of the timeout. |
| UnableToSetCookie | unable to set cookie | Requests for setting the cookie value cannot be satisfied. |
| NoSuchWindow | no such window | Command for switching to the desired window cannot be satisfied, as the Window is not found. |
| InvalidCookieDomain | invalid cookie domain | Illegal attempt to set a cookie under a different domain than the current page. |
| UnexpectedAlertOpen | unexpected alert open | Modal dialog is open, thereby blocking the current operation. |
| ScriptTimeout | script timeout | Script is unable to complete before the expiry of the timeout. |
| InvalidElementCoordinates | invalid coordinates | Coordinates supplied to the interactions operation are not valid. |
| SessionNotCreatedException | session not created | Unable to create a new session. |
| NoAlertOpenError | no such alert | Attempt for operating on a modal dialog box when it is not open. |
| MoveTargetOutOfBounds | move target out of bounds | Target that is provided to the move action is out of bounds. |
| stackTrace | stacktrace | An array of JSON objects that describe the stack trace for the exception thrown when the desired command failed. |
| InvalidSelector | invalid selector | Argument was an invalid Selector (XPath, CSS, Name, etc.) |
The W3C specification for WebDriver and now-obsolete WebDriver Wire Protocol is an excellent reference to keep an eye on the differences between both the protocols. The follow-up question that comes up after looking at discrepancies between JSON Wire Protocol and WebDriver W3C protocol is ‘What is the impact of WebDriver W3C protocol on existing test automation implementation’?
Impact of WebDriver W3C Protocol on an existing implementation
WebDriver W3C Protocol has been a part of Selenium since Selenium v3.8, but the Selenium WebDriver implementation was backward compatible (with the JSON Wire Protocol). However, the JSON Wire Protocol will be completely phased out in Selenium 4. This essentially means you might already be using WebDriver W3 protocol even though the tests are executed on a Selenium 3 Grid. The latest stable version of Selenium 3 (i.e., Selenium 3.141.59) already has support for the W3C protocol. The same is evident from the release history of Selenium 3.141.59.
The changes are transparent to the developers and automation testers of the Selenium framework. The wire protocol level changes are supposed to enhance the API level owing to which tests would be less flaky and uniform across different browsers (and versions).
For example, ChromeDriver version 75 onwards runs in the W3C standard-compliant mode by default. Developers and users of the Selenium framework had faced few issues with their tests, but the issue was fixed after updating the respective ChromeDriver.
Here are the screenshots of automated Selenium testing using ChromeDriver (version 86.0) executed on a local Selenium Grid (version 3.141.59). By default, it is using the WebDriver W3C protocol for communication.
Impact of WebDriver W3C Protocol on Automation Tests executed on LambdaTest
For users of the cloud-based Selenium Grid facilitated by LambdaTest, Selenium’s migration to WebDriver W3C protocol should not cause any impact. No changes are required in the existing automated Selenium testing scripts, as LambdaTest chooses the appropriate Selenium WebDriver protocol to work without hassles.
Here is a screenshot of a Selenium automation test executed on the cloud-based Selenium Grid by LambdaTest:
As seen in the screenshot, the WebDriver W3C protocol was used for automated Selenium testing.
Wrapping Up
WebDriver W3C protocol offers numerous benefits when compared to the JSON Wire Protocol. All the modern web browsers also use the W3C protocol, avoiding the need for API encoding and decoding in Selenium 4 (which uses the WebDriver W3C protocol). The issues that automation testers faced when porting a Selenium code from one web browser to another will be history with Selenium 4.
Selenium users can expect less flaky, more consistent, and more stable Selenium automation testing with WebDriver W3C protocol in Selenium 4. Though JSON Wire Protocol will retire in Selenium 4, the possibility is that your tests might be using W3C protocol even though they are not tested on Selenium 4. This is because the WebDriver W3 protocol is available in Selenium v3.8 onwards. The catch is that the WebDriver implementation is backward compatible (i.e., if the tests do not work as expected on W3C protocol, they are tested against the JSON Wire Protocol).
To summarize, Selenium 4 Alpha features like W3C compliance will offer a host of benefits to the entire Selenium community. Till then, we wait for the release of the stable version of Selenium 4.
Happy Automation Testing!
Top comments (1)
Interesting. Will wait till a stable release is made.