Setting a custom profile dir with Chrome breaks devtools websocket proxying

[matthewlowry]

I wish to write a suite where a custom Chrome browser profile is prepared and then re-used across a number of sessions.
These tests are also using devtools bidi API (listening for network events and fetching request bodies, specifically).

If I request a Chrome session like this:

{
    "capabilities": {
        "alwaysMatch": {
            "browserName": "chrome",
            "browserVersion": "114.0",
            "goog:chromeOptions": {
                "args": [
                    "user-data-dir=/profiles/abc"
                ]
            }
        }
    }
}

Then I can not connect a websocket client to devtools port of the browser anymore. E.g. if I use wscat:

> wscat -c ws://127.0.0.1:4444/devtools/<SESSIONID>/
error: Unexpected server response: 200

If I look in the logs for the session (via the Selenoid UI), I see this:

2023/06/23 01:23:57 [BROWSER_URL_ERROR] [failed to get browser websocket url: could not resolve IP for 127.0.0.1]

These errors go away if I request a session that does not pass a custom user-data-dir argument to Chrome. Is there something else I need to do when passing a custom user-data-dir to Chrome so I don't break devtools websocket proxying?

Just for clarity - the intention is to use "volumes":[ "/host/dir:/profiles" ] to pass the custom profile dir across sessions, but this error occurs with or without mounting a host directory into the container. The error also occurs if I use user-data-dir=/tmp/foo or similar.

[matthewlowry]

Ahhh. OK, started digging and think I worked it out.

It does indeed break the logic for finding the DevToolsActivePort file that Chrome process creates in the profile directory. This logic assumes chromedriver's default behaviour of generating a temporary browser profile at /tmp/.com.google.Chrome.XXXXXX.

So the work-around is to always use /tmp/.com.google.Chrome as a prefix for the directory you are mounting into the container.

[vania-pooh]

@matthewlowry you are right. Currently this is hard-coded.

[matthewlowry]

@vania-pooh Thanks. Now I've got my head around how it works I've written a little patch to enable passing an environment variable into the container to point at the custom browser profile directory. I'll close this issue and raise a PR over in the images repo.

[v4dkou]

@matthewlowry devtools seemingly only needs the profile dir to find the remote debugging port, and if the file's not found it defaults to 9222. Chrome can be launched with the --remote-debugging-port=9222 argument, so that devtools could then connect via the default URL.

Works fine for me, but perhaps there's some use case where that would fail that I am not thinking about?

Also, the benefit of using --remote-debugging-port=9222 is that old Chrome images work fine without updating devtools with a new build (which didn't work for me right off the bat for some reason, and I decided not to investigate it yet, opting for a simpler solution)