[MGNLTEST-444] Selenium DevTools and the "Augmenter" Created: 15/Oct/23  Updated: 16/Oct/23

Status: Open
Project: Magnolia Test Framework
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Neutral
Reporter: Bertrand Renuart Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Team: Foundation

 Description   

The Selenium class is "augmenting" the remote driver when the DevTools are enabled in order to overcome the following limitation (text copied from the class Javadoc):

This class is copy of the {@link org.openqa.selenium.remote.Augmenter} which filters out the default devtools provider which incorrectly uses the docker internal IP address instead of host exposed port for resolution of cdp url for establishing connection to the remote web driver running on docker.

However, it is worth to note that the official way to resolve this issue when the grid is running inside a Docker container is to start the container with the `SE_NODE_GRID_URL` environment variable set to the "external" address of the container. See Grid Url and Session Timeout for more information.

Also it seems that although the current "workaround" solution works for CDP, it doesn't seem to cover all the cases and breaks the BiDi interface introduced in v4 (which is working seamlessly when the grid is started with the above mentioned environment variable).

Proposition is to remove the custom augmenter used to provide DevTools access when running in Docker container in favour of starting it with the appropriate environment variable. This may require little changes in how the containers are started, but will ultimately give official support to all features.

 


 

The "DevTools" support in the Selenium class not only "enables" the DevTools support, but also registers a couple of additional listeners that are mainly used during special debugging scenarios. However, DevTools can be used through normal test scenarios to get access to logs, network settings or else. As such, the DevTools interface should always be activated for RemoveWebDrivers - as it Is for local drivers.

Chrome, Firefox and Safari drivers support different features. Each feature is represented by a dedicated Selenium interface like `HasDevTools`, `HasBiDi`, `HasLogEvents`, etc. Since the RemoteWebDriver needs to be connected to a "concrete" driver, it cannot implement these interfaces from the start. To overcome this limitation, the driver needs to be "Augmented" to provide the interface corresponding to the actual features supported by the driver the remote is connected to. This is achieved by "Augmenting" the remote driver to "inject" the interfaces actually supported through byte code manipulation.

Proposition is to always "Augment" the RemoveWebDriver, should the DevTools be enabled or not via the `selenium.enable.devTools` system property.

Note: one will notice that "selenium.enable.devTools" doesn't actually enable the Devtools as the name suggests. It is more a "verbose" feature logging the interactions with the browsers... Should its name be changed ?

 



 Comments   
Comment by Christoph Meier [ 16/Oct/23 ]

brenuart,
as a preamble I need to admit that I likely was too lazy to fully dig into Selenium DevTools, when rdhar enabled Selenium DevTools via MGNLTEST-258.

And ... until now, I still didn't go that deep to understand it fully ... but I may do it. But before I'll do that - two remarks and one question:

Remark I
If not yet done, please have a look at the PRs from Rishab and the comments

Also consider to discuss this ticket directly with Rishab.

Remark II
In the ticket you mention:
"... This may require little changes in how the containers are started, ..."
tbh this worries me a bit.
We already have a certain complexity in our docker-setups, that's especially true for the projects running on SRE-jenkins, where we may run several projects on the same jenkins-node, which makes the port-assignments a bit tricky. Changing the set-ups will be time consuming.

The question
I understand the statement "... but will ultimately give official support to all",
my question, for now, is: Do we currently lack some features of the Selenium DevTools, if yes, where would you need which currently unavailable feature?

¯_(ツ)_/¯

Generated at Mon Feb 12 07:49:01 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.