Chrome Connection
Overview
ChromeDriver uses several classes to connect to Chrome and control it.
Chromeclass represents the Chrome browser controlled by ChromeDriver.DevToolsClientclass represents a connection to Chrome.WebViewclass wraps around aDevToolsClientto provide some higher level methods.
Chrome class
ChromeDriver uses abstract class Chrome to represent the Chrome browser that
it controls. Other classes derived from it provide the actual implementations.
Here is its inheritance hierarchy:
Chrome: Abstract base class, defining the API.ChromeImpl: Still an abstract class, it contains implementation code that is shared by concrete classes.ChromeDesktopImpl: Represents a local desktop Chrome browser.ChromeAndroidImpl: Represents an adb connection to a Chrome running on an Android device.ChromeRemoteImpl: Represents a Chrome browser that is started independently from ChromeDriver, and is connected through a TCP port. The browser can be running locally or remotely.
StubChrome: An implementation with all methods stubbed out, used for unit tests only.- Various test classes.
There is a separate instance of ChromeImpl for each ChromeDriver session.
It has several fields related to the connection between
ChromeDriver and the browser:
-
ChromeImpl::devtools_http_client_is aDevToolsHttpClientobject. It contains the URL necessary to connect to browser DevTools (e.g., http://localhost:12345), but doesn't contain any actual connections. -
ChromeImpl::devtools_websocket_client_is aDevToolsClientobject. It encapsulates a browser-wide DevTools connection, used for sending commands that apply to the whole browser. This instance ofDevToolsClientis sometimes referred to as the "browser-wideDevToolsClient". -
ChromeImpl::web_views_is a list ofWebViewobjects, one for each tab active in the browser. These objects are used for sending commands that apply to a specific tab.Chrome::GetWebViewByIdallows retrieving aWebView(tab or page) by its ID. (There are additionalWebViewinstances that represent frames, butChromeImplis not aware of them.)
DevToolsClient and WebView
Abstract class DevToolsClient and its
implementation class DevToolsClientImpl
handle communication between ChromeDriver and DevTools.
DevToolsClient contains methods to connect to Chrome,
send commands to Chrome, and receive responses and events from Chrome.
Changes are rarely needed at this level to implement new features.
The abstract class WebView and its implementation
class WebViewImpl contain higher-level
methods on top of DevToolsClient. In addition to wrappers to methods
provided by DevToolsClient, it also has higher level methods for
synthetic event dispatching, cookie handling, etc.
The rest of ChromeDriver usually interacts with Chrome through WebView class.
There are several types of DevToolsClient and WebView instances:
-
Browser-wide
DevToolsClient, with no matchingWebView. It has id"browser". -
DevToolsClientandWebViewrepresenting a tab or window. Both should have the same id, a 32-digit uppercase hexadecimal number. -
DevToolsClientandWebViewrepresenting an OOPIF (out-of-process iframe, i.e., a frame connected to a different renderer process than its parent frame). They are created in response toTarget.attachedToTargetevent from DevTools. Each OOPIF has atargetIdand asessionId(not to be confused with ChromeDriver's session ID), both 32-bit hexadecimal numbers. TheDevToolsClientuses thesessionIdas its ID, and has a parentDevToolsClient. TheWebViewuses thetargetId(same asframeId) as its ID, and has a parentWebView. No real connections are made. All communications are forwarded by the parentDevToolsClientandWebView.
Note that in most case, each instance of DevToolsClient is wrapped by a
WebView. The browser-wide DevToolsClient is the only instance not wrapped.
From the point of view of the client application, each browser tab or window is
represented by a window handle, the DevToolsClient, and WebView
representing the tab/window. Each session has a tab that is currently active.
The WebView connected to that tab can be retrieved with
Session::GetTargetWindow.