How does chromedriver.exe work on a core and fundamental level

Question

I know that Selenium Webdriver is evolved from Selenium RC. Server in the Selenium RC was used to overcome the "same origin policy" using the proxy injection. Is it that the chromedriver.exe performs same functions? I tried find the answers online could not get any satisfactory explaination. Thanks in advance.

Answer 1

Sadly none of the answers above are explaining what the real question here is. To understand how the chromedriver works fundamentally, you need to understand the root first.

What is WebDriver anyway?

Selenium WebDriver or WebDriver, as it is called, is actually an open source tool for automating testing of web-apps across many browsers. It does that by simulating the user actions on a webpage, like clicking on a button, filling out forms etc.

How does WebDriver communicates with Web Browser

Glad you asked. WebDriver communicates or messages the browser (Chrome/Firefox/Safari/IE) using an specific protocol. This is called the WebDriver JSON Wire Protocol, which is actually a RESTful web service using JSON over HTTP

All implementation of WebDriver - whether it is the ChromeDriver, the GeckoDriver, the IEServerDriver need to use this wire protocol to communicate with the respective browsers.

The wire protocol is implemented in request/response pairs of "commands"and "responses".

Oh Really! How Does It Happen?

Ok. I'm not going that far into it. To understand how this wire protocol communicates using the respective implementation, you need to know and read more about the messaging and response from the protocol. The Selenium project's Github account is a good place and it has been explained in detail here about the wire protocol.

Hey, But What About ChromeDriver?

Oh yeah! ChromeDriver is the extension of the WebDriver's wire protocolfor Chromium.

ChromeDriver actually is a standalone server which implements WebDriver's wire protocol for Chromium. It comes in an executable form, which can be downloaded from theChromeDriver's` website.

ChromeDriver actually consists of three separate pieces -

1. Browser - The Chrome browser itself.
2. Language Bindings (Driver) - Particular language bindings available in Java/Python/PHP/C# that you can directly use in your program/script to send commands to the ChromeDriver

For example, in Java you call this

 import org.openqa.selenium.chrome.ChromeDriver;

3. ChromeDriver - The final and most important piece of this trilogy is the executable (that I just talked above), which acts as a bridge between "chrome" - from 1 and the "driver" from 2.

So, it is actually a middleman between your code and your browser- yikes sounds gross.

Here is a good read.

Answer 2

Selenium WebDriver has compatbility in pretty much most major browsers and programming languages. WebDriver has multiple interacting components:

• A web browser.
• A plugin/Extension to the browser (which resides inside the browser, which contains a server that implements the WebDriver JSON API).
• A language binding which makes HTTP requests, to the previously mentioned API.

When you start code that uses WebDriver, it will open up the browser, which in turn starts the plugin. You can then send requests to perform the actions you want, such as clicking on links or typing text. As a plugin only needs to implement the JSON API, people have written plugins for all major browsers. To use a browser that has a plugin, you just need to implement a client to the JSON protocol.

Answer 3

Selenium Remote Control (RC) and Selenium WebDriver both are test automation tools supporting different programming languages but come with some critical differences.

---

Selenium RC

Till a couple of years back Selenium RC was an important component in the Selenium test suite. It was the testing framework that enabled a QA or a developer to write test cases in any programming language in order to automate UI tests for web applications against any HTTP website. Selenium RC comprised of two parts:

• Client libraries for the preferred Language Binding Art.
• A server that launches and destroys web browsers automatically.

Selenium RC’s architecture was a bit complicated as:

• Developer/QA personal needed to install and launch a separate application called Selenium Remote Control Server before running test scripts.
• The Selenium RC server acted as a mediator between the browser and Selenium commands.

The sequence of execution was:

• The Selenium RC server injected a Javascript program known as Selenium Core into the browser client.
• Once the Selenium Core program was injected, it started receiving instructions from the RC server based on test scripts. Selenium Core executed all these instructions as JavaScript commands.
• The web browser executed all the commands given by Selenium Core and returns the test summary back to the Selenium RC server.

But there were limitations as follows:

• Selenium RC Server's architecture was pretty complicated.
• Execution of test scripts was time-consuming as Selenium RC uses JavaScript commands as instructions to the browser which resulted in slow performance.
• API’s were less object-oriented.
• There was no support for headless browsers.

All these limitations of Selenium RC Server led to the development of the new robust automation framework Selenium WebDriver.

---

WebDriver

From Selenium's perspective, the WebDriver Interface is similar like a agreement which the 3rd party Browser Vendors like Mozilla, Chrome, Internet Explorer, Safari, etc have to adhere and implement the same. This would in-turn help the end-users to use the exposed APIs to write a common code and implement the functionalities across all the available Browsers without any change.

---

Communication through commands

The WebDriver protocol is organised into commands. Each HTTP request with a method and template defined in the specification represents a single command and hence each command produces a single HTTP response. In response to a command, the remote end will run a series of actions known as remote end steps. These provide the sequences of actions that a remote end takes when it receives a particular command.

---

Command Processing

The remote end is an HTTP server reading requests from the client and writing responses typically over a TCP socket. In the specification the communication is modeled as the data transmission between a particular local end and remote end with a connection to which the remote end may write bytes and read bytes. The exact details of how this connection works and how it is established is a bigger topic and out of scope for this question. After a connection has been established, the remote end must read bytes from the connection until a complete HTTP request can be constructed from the data. If it is not possible to construct a complete HTTP request, the remote end must either close the connection, return an HTTP response with status code 500, or return an error with error code unknown error.