Open drzraf opened 3 years ago
Hi @drzraf 👋
Thanks for submitting this issue. 👍 Since it is a chromium bug, I cannot help that much with the use of this Docker image.
I've read the workaround. You've seen the example with socat
. Does it work for you?
I wouldn't say it's a chromium bug. It's just a "strange behavior". In order to workaround it, extra tools are needed (ssh/socat), and since remotely-driven (--remote-debugging
) headed seems a legitimate use-case, I suggest to bundle the necessary tools into the bundle.
I didn't tested the socat workaround myself but it sounds simple and logical and I'm confident it'd work.
Hi @drzraf 👋
Your workaround with socat
need to install libraries on the host. I think it is not need in the container but need in the host launching the container. Am I wrong?
Feel free to add a fully example if you succeed. 👍
Context
When running
zenika/alpine-chrome:86
orzenika/alpine-chrome:with-webgl
in headed mode, their is chromium gotcha: Contrary to--headless
, this will not bind the socket to the external container interface but only to 127.0.0.1 (https://stackoverflow.com/a/44200427/5441588):chromium-browser --no-sandbox --remote-debugging-address=0.0.0.0 --remote-debugging-port=9222
As such there is no possibility to use x11 docker and still rely on devtools.
Alternatives
The immediate solution that comes to mind is
ssh
(orsocat
, as suggested on this page), but none of them is installed by default. Since it's a common use case (X-enabled chromium + devtools) and this tools are lightweight, I think it would make sense to bundle them in the images or even provide some facility to get the socket correctly bound out of the box.If the feature request is accepted, would you be willing to submit a PR?
No