Websocket data connectivity issue with Chrome headless?

Component	Version
Operating system	macOS 10.15.7
Node.js	-
Chrome/Chromium/…	87.0.4280.88
chrome-remote-interface	-

Is Chrome running in a container? YES / NO

Hi Cyrus, Good Day to you!

I’m maintaining 2 digital automation tools (TagUI, and RPA for Python, a Python wrapper of the former). Recently I found that TagUI is not able to receive response back from Chrome websocket connection if it is run in headless mode. But the same code works fine with visible mode. Nothing changed from my side, so I suspect something changed with Chrome.

Did some troubleshooting but not getting any clues (https://github.com/kelaberetiv/TagUI/issues/890) and have not found anything from the internet. Thought to raise an issue here to see if you or your users have run into problems with Chrome headless as well.

The gist is after a websocket message is sent, it can take more than 10 seconds for the headless Chrome process to send back the response. Running the same code with Chrome visible gets instant response.

Best Regards, Ken

[cyrus-and]

I see, hopefully people running in the same problem will find this issue.

Happy 2021 to you too! ^_^

[kensoh]

Thanks Cyrus for your quick reply!

It seems like a situation unique with my implementation for TagUI. What happens is in headless mode, when I provide --user-data-dir= with a relative path it no longer works, when it used to work in the past 2 years. When I tweak the relative path provided into a full path, it works in headless mode. For visible mode, it works whether relative or absolute path is provided.

Something probably has changed with how headless Chrome behaves when the path provided is a relative path. I’ll close this issue because I don’t think it happens outside of the TagUI implementation. I tried replicating the issue using Python websocket but it can’t be replicated. So the fix has to be an updated implementation for TagUI headless Chrome.