Enable a browser to be used within the dev container.

[seanybaggins]

It would be nice if I am working on a rust project if I could open the generated documentation using cargo doc --open. Instead I get the following warning

warning: couldn't open docs

command 'xdg-open (internal)' did not execute successfully; exit code: 3
command stderr:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Couldn't find a suitable web browser!
Set the BROWSER environment variable to your desired browser.
Warning: program returned non-zero exit code microsoft/vscode-dev-containers#1
sh: 881: www-browser: not found
sh: 881: links2: not found
sh: 881: elinks: not found
sh: 881: links: not found
sh: 881: lynx: not found
sh: 881: w3m: not found
xdg-open: no method available for opening '/workspaces/rust-interoperability/rust/target/doc/rust_code_callable_from_c/index.html'

It would be nice if this functionality existed without needing to explicitly mount the browser on the host to the container and setting BROWSER environment variable within the Dockerfile.

[Chuxel]

Hmmm - interesting question. Unclear how we could make that work. We do not want to mount the browser since this would not work in when the host is remote, and conceivably the URI needs to be forwarded if it was pointing to localhost. In some cases, you may actually want xdg-open to open a browser in a container as well (like in the case of https://github.com/microsoft/vscode).

[PavelSosin-320]

Do you mean headless chrome? You can always install a stack of 2 containers: development container and one of the multiple containers packing headless chrome on the same docker network.

[seanybaggins]

I don't think I mean a headless browser. All I do know is it would be nice if in the vs code remote container, you could use your browser as you would normally.

examples:

executing cargo doc --open would just open the documentation.

executing firefox (or whatever your browser is) in the terminal, would just open your browser on your host.

[PavelSosin-320]

You can't use your browser from inside the container and will never be able to do it. Docker container has no access to the host's drivers or GPU for common purposes. The docker container is always headless - it communicates with the outside world via tty or TCP/UDP ports. The sweet exception is NVIdia containers which can use GPU for calculation purposes only, i.e. Cuda, Tensorflow. If you need a browser for testing than Headless Chrome is good for you as it is proved by all Testing automation frameworks. If you want to render your server response you have to use a browser connected to your server via TCP. It is feasible to launch a browser automatically at debugging session startup but always from the debugger side.

[PavelSosin-320]

@seanybaggins What is written exactly about runtime resource allocation by Docker container, please, read Runtime resource allocation. To see the web page on the screen the following virtual resources are required: display memory, HDMI or USB3 cables, display panel. Since the browser uses TCP for communication and builds DOM before pixel rendering, Headless Chrome does everything except pixel rendering. Max feasible is : RDP server!, pupetter or HeadfulChrome

[alahijani]

The solution implemented by xdg-open-server seems simple and elegant: xdg-open in the container uses a shared socket to delegate it to the external UI. I guess the vscode-remote protocol could easily add support for something along those lines.

I suspect something like that already exists internally (whatever mechanism handles github logins for example), it just needs to be exposed on the command line inside the container. Something like code --open-browser https://....

[mvgijssel]

Currently running into this as well! Trying to get credentials using DUO OIDC provider which requires opening a browser window as well. A simple code --open-browser https://... would be perfect! Existing solution would be something like this https://github.com/superbrothers/opener.

[mvgijssel]

Trying https://github.com/devcontainers/features/tree/main/src/desktop-lite#example-usage to see if this solves our use case for now.

[mvgijssel]

After setting up the desktop-lite feature noticed that VSCode is already exposing the BROWSER environment variable like

BROWSER=/vscode/vscode-server/bin/linux-arm64/d045a5eda657f4d7b676dedbfa7aab8207f8a075/bin/helpers/browser.sh

Installing xdg-utils inside of the devcontainer and running xdg-open https://google.com results in

Which then actually opens the browser window on the host machine! No need for the desktop-lite feature.

[burtonrodman]

My solution in a C# (.NET) devcontainer: in devcontainer.json

    "postCreateCommand": "bash ./.devcontainer/postCreateCommand.sh",

in postCreateCommand.sh

sudo apt-get update
sudo apt-get install -y xdg-utils

[chrmarti]

Continuing in https://github.com/devcontainers/images/issues/885.