[🚀 Feature]: Use self-managed browsers in Docker containers

[bonigarcia]

Feature and motivation

It would be helpful to have an easy way to use dockerized browsers instead of local browsers (for example, when using ChromeDriver). Dockerized browsers will allow the implementation of another handy feature: having the browser recordings out of the box.

Usage example

My vision is the following. I create a Selenium session as follows. The syntax can change, but the important thing is that I specify to use a Dockerized browser somehow (maybe even an environment variable can be helpful):

ChromeOptions options = new ChromeOptions();
options.useDocker();
WebDriver driver = new ChromeDriver(options);

Internally, the bindings will call Selenium Manager to create a browser (Chrome, in this case) in a Docker container. For that, we will use the container images maintained by Selenium, i.e., docker-selenium. Something like this:

./selenium-manager --browser chrome --docker --debug
[DEBUG] Pulling Docker image selenium/standalone-chrome:latest (this might take some time, but only the first time)
[DEBUG] Starting Docker container selenium/standalone-chrome:latest
[DEBUG] Creating WebDriver object for chrome at http://localhost:57638/ with Capabilities {browserName: chrome, goog:chromeOptions: {args: [--disable-gpu], extensions: []}}
[DEBUG] The sessionId is db2bdb79a1a313c0bb8cc011a1f9694b
[INFO] Remote URL: http://localhost:57638/

From this output (as usual, also available as JSON), the bindings will read the remote URL (http://localhost:57638/ in the example before) to create a RemoteWebDriver instance. For that, something similar to #14451 will be required (i.e., the capability to instantiate a RemoteWebDriver instead of ChromeDriver).

The bindings should be able to store some state about this (typically, the session ID, since when the user calls driver.quit(), the bindings should call Selenium Manager again to dispose of the Docker container properly. Something like:

./selenium-manager --quit db2bdb79a1a313c0bb8cc011a1f9694b

This feature will allow the use of only Docker to provide any browser release available in the Docker hub (such as 127.0, but also latest, beta, dev, etc.). More importantly, it will allow us to implement session recording easily. My vision is the following:

ChromeOptions options = new ChromeOptions();
options.useDocker();
options.enableRecording();
WebDriver driver = new ChromeDriver(options);

With this, the bindings will call Selenium Manager as follows:

./selenium-manager --browser chrome --docker --recording --debug
[DEBUG] Pulling Docker image selenium/video:latest (this might take some time, but only the first time)
[DEBUG] Starting Docker container selenium/standalone-chrome:127.0
[DEBUG] The sessionId is The sessionId is 7bac122c873606f01807905229e1a3f0
[DEBUG] Starting Docker container selenium/video:latest
[DEBUG] Starting Docker container selenium/standalone-chrome:latest
[DEBUG] Creating WebDriver object for chrome at http://localhost:57694/ with Capabilities {browserName: chrome, goog:chromeOptions: {args: [--disable-gpu], extensions: []}}
[DEBUG] Starting recording .\chrome_2024.08.28_18.08.44.647_7bac122c873606f01807905229e1a3f0.mp4
[INFO] Remote URL: http://localhost:57714/

At the end of the session, the user will have a local MP4 file containing the browser recording. This recording can be super helpful for troubleshooting.

Lastly, and since the docker-selenium images are prepared to use VNC, we could provide a noVNC URL to debug the browser in Docker easily, something like:

ChromeOptions options = new ChromeOptions();
options.useDocker();
options.enableVnc();
WebDriver driver = new ChromeDriver(options);

Pros
· We rely on Docker to manage the browser infrastructure.
· Having recordings in Selenium is a very appealing feature for users.
· We already have the docker-selenium images.
· Most of the work is implemented in Rust. The bindings simply call it.

Cons
· Most of the work is implemented in Rust. I am up to implement it, but I will need time. For that, I see this feature implemented in the long run.
· Some changes related to how remote driver instances are created are required in the bindings (see #14451).