[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: |
| 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):
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, 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
Also consider to discuss this ticket directly with Rishab. Remark II The question ¯_(ツ)_/¯ |