Not being able to launch a Tauri application from a devcontainer

[delucca]

Hey 😄

I've been trying for many days to launch a simple Tauri application from within a devcontainer. The application was created by following Tauri's NextJS quick start

If I run the application with npm run tauri dev outside the devcontainer, it works as expected. If I run it inside the devcontainer, I can open localhost:3000 on my browser and see the application as expected, but the desktop window that opens is blank. If I try to inspect the window I can see that I have all the HTML and elements, but for some reason it is blank (even the mouse change pointers when I reach a place in which there is a link)

On my terminal, I get the following:

vscode ➜ /workspaces/tauri-quickstart $ npm run tauri dev

> [email protected] tauri
> tauri dev

     Running BeforeDevCommand (`npm run dev`)

> [email protected] dev
> next dev

        Info Watching /workspaces/tauri-quickstart/src-tauri for changes...
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s

(my-app:3592): dbind-WARNING **: 05:24:51.002: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/1000/at-spi/bus_1: No such file or directory
Gtk-Message: 05:24:51.015: Failed to load module "canberra-gtk-module"
Gtk-Message: 05:24:51.016: Failed to load module "canberra-gtk-module"
Gtk-Message: 05:24:51.056: Failed to load module "canberra-gtk-module"
Gtk-Message: 05:24:51.057: Failed to load module "canberra-gtk-module"

** (WebKitWebProcess:3604): WARNING **: 05:24:51.075: Can't connect to a11y bus: Could not connect: No such file or directory
libEGL warning: DRI3: Screen seems not DRI3 capable
libEGL warning: DRI2: failed to authenticate
  ▲ Next.js 13.5.2
  - Local:        http://localhost:3000

 ✓ Ready in 2.4s
 ✓ Compiled /page in 824ms (484 modules)
 ✓ Compiled in 187ms (234 modules)

My devcontainer is basically this:
.devcontainer/Dockerfile

ARG VARIANT="focal"
FROM mcr.microsoft.com/vscode/devcontainers/base:0-${VARIANT}

ARG TAURI_BUILD_DEPS="build-essential curl libappindicator3-dev libgtk-3-dev librsvg2-dev libssl-dev libwebkit2gtk-4.1-dev wget libwebkit2gtk-4.0-dev"

RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
    && apt-get install -y --no-install-recommends $TAURI_BUILD_DEPS

.devcontainer/devcontainer.json

{
  "name": "Ubuntu",
  "build": {
    "dockerfile": "Dockerfile",
    "args": { "VARIANT": "ubuntu-22.04" }
  },
  "runArgs": [
    "--privileged",
    "--net", "host",
    "-e", "DISPLAY=${localEnv:DISPLAY}",
    "--gpus", "all"
  ],
  "remoteUser": "vscode",
  "features": {
    "node": "lts",
    "rust": "latest"
  },
  "mounts": [
    {
      "source": "/run/user/1000/gdm/Xauthority",
      "target": "/home/vscode/.Xauthority",
      "type": "bind"
    },
    {
      "source": "/tmp/.X11-unix",
      "target": "/tmp/.X11-unix",
      "type": "bind"
    }
  ]
}

About my environment:

• I'm using an Arch Linux
• My window manager is X11
• For some reason my $DISPLAY env variable is set to 1 🤔

A few things I've already tried:

• I've already tried adding the add_host to the run-args in order to use the host.docker.internal:1, it doesn't work neither
• I've already tried installing the canberra-gtk-module, it doesn't work too (but the warning about that module disappears)

Anyone can give me a hand? 😢 I have no idea how to solve this

---

Edit 1: I've just follow this tutorial and it seems both glxinfo and glxgears are producing the expected results (Yes for the direct rendering and the gears are opening in a window) but I'm still getting the DRI error on tauri

Edit 2: If I run export LIBGL_ALWAYS_SOFTWARE=1 and after this I run npm run tauri dev the DRI errors disappear, but the application screen that opens is still blank for some reason

Edit 3: I've just added "-v", "/run/user/1000/at-spi/bus_1:/run/user/1000/at-spi/bus_1:rw" to my runArgs and now I don't have any other error/warning when running tauri dev, but still the window that opens with the application is blank 😢. The only error I've receive is after a few seconds of the app running with the blank screen I get this:

** (my-app:4277): WARNING **: 06:10:22.134: atk-bridge: get_device_events_reply: unknown signature

Edit 4: If I try tweaking on the console of the blank page that opens, I get these errors:

libEGL warning: failed to open /dev/dri/card1: Permission denied

libEGL warning: failed to open /dev/dri/card0: Permission denied

After this, I've noticed that the /dev/dri/card0 and also the card1 were on the group 985, which is the ID of the video group of my host machine. I've changed the GID of the video group of the devcontainer (which was 44) and restarted the container to get a new shell, but the issue persists

Edit 5: I've tried installing the libnvidia-gl-535 package, now I'm always getting this error:

> next dev

        Info Watching /workspaces/tauri-quickstart/src-tauri for changes...
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
EGLDisplay Initialization failed: EGL_BAD_ACCESS
Cannot create EGL sharing context: invalid display (last error: EGL_SUCCESS)

(WebKitWebProcess:16920): Gdk-ERROR **: 06:25:55.801: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 228 error_code 2 request_code 152 (GLX) minor_code 34)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
  ▲ Next.js 13.5.2
  - Local:        http://localhost:3000

 ✓ Ready in 2.5s

[delucca]

After a lot of debugging I found this issue

I've added WEBKIT_DISABLE_COMPOSITING_MODE=1 to my env vars and this solved the problem. Will this have effect on the performance of the app that is running on the devcontainer? 🤔

[FabianLars]

I honestly don't understand why specifically for this use case this is an issue

Well, let's just say you found that env var in this repo's issues for a reason. It fixes the weirdest issues in webkitgtk, even things you'd expect to be completely unrelated to gpu/acceleration/compositing... In this case webkitgtk's implementation is probably somehow just really picky about something (that's the most helpful sentence ever lol) 😞

[delucca]

yeah it makes sense. I understand that if this problem is ever solved that issue I've linked in the answer would be closed right? So I'll subscribe to it and follow-up

Thanks for your patience and the amazing work on the tool 🙌🏻

[FabianLars]

I understand that if this problem is ever solved that issue I've linked in the answer would be closed right?

Maybeeeee. That issue contains a few potentially unrelated issues. For example the accessibilty thing from the title has nothing to do with accelerated compositing. It's just that the accessibility warning shows up quite often so people think it's related to whatever other problem they have. On top of that the env var also fixes the most random problems so i'm not so sure if that linked issue is of any relevance for you.

I'd tend to say that trying it again on each webkitgtk update may be more helpful than that issue idk.

[elyalon]

I had the same issue, and the problem has something to do with vscode / vscode's terminal, because when i start the app from a normal terminal it works fine.

I declared the variable in vscode settings like this:

// settings.json

"terminal.integrated.env.linux": {
    "WEBKIT_DISABLE_COMPOSITING_MODE": "1",
},

[ramipellumbi]

I had the same issue, and the problem has something to do with vscode / vscode's terminal, because when i start the app from a normal terminal it works fine.

I declared the variable in vscode settings like this:

// settings.json

"terminal.integrated.env.linux": {
    "WEBKIT_DISABLE_COMPOSITING_MODE": "1",
},

Now this ... is interesting. Same thing for zed terminal vs. regular terminal - works via regular but the above issue occurs when executing via Zed.