Chromedriver UI interaction hangs and eventually times out when the same browser is being viewed via chrome://inspect

user_1644596 0
Viewed 166

I have the following set up:

  • Docker container running webdriver driven test where the chrome debugger port has been exposed; chrome, chromedriver and the test script are running inside docker
  • "chrome://inspect" in a locally hosted Chrome is attached to "localhost:{chrome debugger port in the container}"

This is initially working fine, and I can see the resize and navigation automation take place via "chrome://inspect"; both visually and via the network tab.

However, if the test now performs a UI interaction (e.g. Click), then the test now hangs.

In the chromedriver log I can see the following:

{
    "level": "INFO",
    "message": "[5339224edf3cdb41717d411be555e498] COMMAND ClickElement {\n   \"id\": \"0.621529095214542-11\"\n}\n",
    "timestamp": 1651839457863
  },
  {
    "level": "INFO",
    "message": "Waiting for pending navigations...\n",
    "timestamp": 1651839457863
  },
  {
    "level": "INFO",
    "message": "Done waiting for pending navigations. Status: ok\n",
    "timestamp": 1651839457869
  },
  {
    "level": "SEVERE",
    "message": "Timed out receiving message from renderer: 600.000\n",
    "timestamp": 1651840058224
  },
  {
    "level": "INFO",
    "message": "Waiting for pending navigations...\n",
    "timestamp": 1651840058226
  },
  {
    "level": "INFO",
    "message": "Done waiting for pending navigations. Status: ok\n",
    "timestamp": 1651840058230
  },
  {
    "level": "SEVERE",
    "message": "Timed out receiving message from renderer: 600.000\n",
    "timestamp": 1651840657613
  },
  {
    "level": "INFO",
    "message": "Waiting for pending navigations...\n",
    "timestamp": 1651840657614
  },
  {
    "level": "INFO",
    "message": "Done waiting for pending navigations. Status: ok\n",
    "timestamp": 1651840657618
  },
  {
    "level": "SEVERE",
    "message": "Timed out receiving message from renderer: 600.000\n",
    "timestamp": 1651841256998
  },
  {
    "level": "INFO",
    "message": "Waiting for pending navigations...\n",
    "timestamp": 1651841256999
  },
  {
    "level": "INFO",
    "message": "Done waiting for pending navigations. Status: ok\n",
    "timestamp": 1651841257002
  },
  {
    "level": "INFO",
    "message": "[5339224edf3cdb41717d411be555e498] RESPONSE ClickElement ERROR timeout: Timed out receiving message from renderer: 600.000\n  (Session info: headless chrome=87.0.4280.141)\n",
    "timestamp": 1651841257003
  },

Now for the strange part... if I scroll the browser via the viewer in "chrome://inspect", the UI interaction becomes unblocked and the test continues. If I continually scroll the page up and down, then the test runs absolutely fine!

It should be noted that the test running in the docker container is also consuming several Chrome Developer Protocol resources itself included Screencasts but I don't understand how having multiple consumers would cause this issue.

Also, if we do not open the browser via "chrome://inspect", everything runs fine

docker webdriver google-chrome-devtools selenium google-chrome
1 Answers

Not really able to reproduce this under docker-chromedriver. If you can share reproduction instructions with the image I will update the answer, but until then we can try excluding some possible causes:

  1. Inspection protocol mismatches

    If the version of the browser with which you're inspecting is different than the version running the tests, there is a chance there'll be subtle inspection protocol changes enough to cause the hang.

  2. Stray inspection overlays

    When opening the inspector, an overlay is rendered above the entire viewport, which is supposed to highlight the element in the inspection tree. This used to be the case. Might be solved by running the latest versions in the container.

    inspection overlay example

  1. GPU rendering

    By default, even in headless mode some rendering is offloaded to the GPU which might kick in and cause freezes when the inspector is open.

    This can be disabled via command-line argument --disable-gpu in the container.

  2. Container IPC Implementation

    There are known issues (1, 2) which are fixed by adding DBUS_SESSION_BUS_ADDRESS=/dev/null to the list of environment variables.

user_6088860
Related