browser
browser copied to clipboard
remote debug session not working
Hi
I'm am trying to get a remote debug session working and can only get it to work with network_mode: host. Unfortunatly that is not an option as the running SPA clients needs to resolve other services via the internal docker DNS service names.
What does work with network_mode: host
tunnel directly into the device with
ssh -i /Users/bas/.ssh/special-identity-rsa -L 0.0.0.0:9222:127.0.0.1:9222 [email protected] -p 22222
or with a balena tunnel (for real remote devices) and then a tunnel trhough that tunnel
balena tunnel e41e86a041857b8db2c75cb4956a32f3 -p 22222:127.0.0.1:4321
// other session
ssh -i /Users/bas/.ssh/special-identity-rsa -L 9222:127.0.0.1:9222 [email protected] -p 4321
The debug session shows up at chrome://inspect/devices#devices but the SPA is not loaded or not working correctly.
So this seems a configuration issue. What coudl it be...
My docker-compose.yaml
browser:
image: bh.cr/balenalabs/browser-aarch64/2.5.1
depends_on:
- controller
restart: always
# we can *not* use `network_mode: host` as the browser container needs to be able resolve hosts running
# inside the docker compose context. In addition we *must* also use an explicit LAUNCH_URL as automatic
# discovery of an exposed http service requires 'work_mode: host'.
# network_mode: host
ports:
# - '5011' # management API (optional)
- "9222:9222" # Chromium debugging port (optional) http://192.168.178.222:9222/
environment:
- LAUNCH_URL=http://controller:5051
- REMOTE_DEBUG_PORT=9222
- KIOSK=1
- LOCAL_HTTP_DELAY=0
- SHOW_CURSOR=0
- PERSISTENT=0
- ENABLE_GPU=1
ignore-gpu-blocklist --enable-gpu-rasterization)
- FLAGS=--disable-extensions --no-sandbox --password-store=detect --kiosk --incognito --disable-translate --disable-ipv6 --bwsi --auto-launch-at-startup --console --disable-sync --enable-accelerated-2d-canvas --noerrdialogs --no-message-box --no-first-run --start-fullscreen --disable-hang-monitor --disable-infobars --disable-logging --disable-sync --disable-settings-window --disable-pinch --overscroll-history-navigation=0 --disable-session-crashed-bubble --content-shell-hide-toolbar --touchscreen-usable-while-screen-off --disable-features="OverscollHistoryNavigation" --ignore-gpu-blocklist --enable-gpu-rasterization --user-data-dir=remote-profile
Hey @basz
Thanks for the report. I'll try and look into it, but up front I don't know when. I'll set myself a reminder for the first week of 2024, and see what I can figure out.
Phil
Hi Phil,
That's more than I dare to ask. Would be great if you could figure this oh it. I'm sure it's a configuration detail but no luck here.
Also asked Omar various places (discord docker and balena forums)
Have a great holiday!
Bas
Hello Phil, just a gentle reminder to this ticket.
Hai Phil. Did you ever managed to have a look at this? I would love to be able to do remote debugging as a support capability.
+1 on this issue. Similar to what was stated above, I exposed the port for remote debugging 9222 in my docker compose with - "9222:9222", added all the correct flags. Within my container I can curl the endpoint and get data, from http://localhost:9222/json. However, I can't get any response when done from the balena host.
If I add network_mode: host, then I can get a response from the balena host. But then when I try to do the same from my remote machine using the ip address of the balena device, I don't get anything back.
It seems that byy design, Chromium binds its remote debugging interface strictly to localhost (127.0.0.1)
I noticed there is a flag to change the address, namely --remote-debugging-address=0.0.0.0 but that didn't work. Seems to be limited to only when in headless mode. Also there has been further changes recently that further restricts this.
-
Add --remote-debugging-address switch support to Chrome for Testing
-
https://blogs.igalia.com/dape/2025/03/25/trace-chrome-easy-remote-tracing-of-chromium/
From trace-chrome: easy remote tracing of Chromium:
The Chromium remote debugging port is disabled by default, but it can be enabled using the command line switch --remote-debugging-port=PORT in the target Chromium instance. This will open an HTTP port in the localhost interface, that can be used to connect. Why localhost? Because this interface does not provide any authentication or encryption. So it is unsafe. It is user responsibility to provide some security (i.e. by using an setting an SSH tunnel between the host and the target device to connect to the remote debugging port).
I did a simple test:
- installed
socatin the container - I had
35173port mapped in mydocker-compose, so I changedREMOTE_DEBUG_PORTto9222 - I ran
socat TCP-LISTEN:35173,fork,bind=0.0.0.0 TCP:127.0.0.1:9222in the container - I added a remote target in
chrome://inspect/#devices