tauri: [bug] Could not determine the accessibility bus address

Describe the bug

Hello,

Might be linked to https://github.com/tauri-apps/tauri/issues/4174, not sure as it’s the same error but not the same case at all.

When trying to run tauri dev for benchmark purpose (https://github.com/Elanis/web-to-desktop-framework-comparison/pull/73), I’m having an error saying Could not determine the accessibility bus address. Google isn’t helping a lot this time 😕

This ends like this:

Building [=======================> ] 366/367: app(bin)                    
Finished dev [unoptimized + debuginfo] target(s) in 7m 31s
Running `target/debug/app`
Could not determine the accessibility bus address

(Link to full logs, with specific line)

Reproduction

Create an empty app
Create a github action CI on ubuntu-latest
- Install recommended linux packages (https://tauri.studio/v1/guides/getting-started/prerequisites#setting-up-linux)
- npx tauri dev

Expected behavior

No response

Platform and versions

Packages
  › @tauri-apps/cli [NPM]: 1.0.0-rc.13
  › @tauri-apps/api [NPM]: 1.0.0-rc.6
  › tauri [RUST]: 1.0.0-rc.14,
  › tauri-build [RUST]: 1.0.0-rc.12,
  › tao [RUST]: 0.9.1,
  › wry [RUST]: 0.17.0,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../dist
  › devPath: ../dist

App directory structure
  ├─ dist
  ├─ node_modules
  └─ src-tauri

Stack trace

No response

Additional context

Here is my pull request where I try to fix that behavior: https://github.com/Elanis/web-to-desktop-framework-comparison/pull/73

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 1
Comments: 24 (6 by maintainers)

Commits related to this issue

fix(gnome+nvidia): make GNOME's online accounts display work correctly There's a bug on NVIDIA cards where Webkit tries to get a weird GStreamer plugin that is not available for some reason. This hap... — committed to cfcosta/home.nix by cfcosta a year ago
fix(gnome+nvidia): xclip + make GNOME's online accounts display work correctly There's a bug on NVIDIA cards where Webkit tries to get a weird GStreamer plugin that is not available for some reason. ... — committed to cfcosta/home.nix by cfcosta a year ago
fix(gnome+nvidia): xclip + make GNOME's online accounts display work correctly There's a bug on NVIDIA cards where Webkit tries to get a weird GStreamer plugin that is not available for some reason. ... — committed to cfcosta/home.nix by cfcosta a year ago
throwing stuff at the wall now <https://github.com/tauri-apps/tauri/issues/4315#issuecomment-1493437583> — committed to firezone/firezone by ReactorScram 4 months ago

Most upvoted comments

WEBKIT_DISABLE_COMPOSITING_MODE=1 solve my problem, thank you. @aveltras

+10

yanganto on Aug 8, 2022

While packaging cinny-desktop for NixOS, I had to run the app with WEBKIT_DISABLE_COMPOSITING_MODE=1 to not get the blank window, seems to be a bug related to nvidia drivers.

+10

aveltras on Aug 8, 2022

Thank you @aveltras.

As NixOS user WEBKIT_DISABLE_COMPOSITING_MODE=1 solved my problem.

j-a-m-l on Apr 2, 2023

So my understanding is Could not determine the accessibility bus address is a warning produced when the a11y accessibility service is not found through D-Bus. Not surprising in a virtual environment and I’ve seen report you can ignore this message and run the application without accessibility support.

I would look to see if you have any other errors besides this warning.

For example in @yanganto’s case:

Cannot get default EGL display: EGL_SUCCESS Cannot create EGL context: invalid display (last error: EGL_SUCCESS)

This is probably the real error to look at. It’s not a very detailed error but not seeing your content rendered and a GL error looks related to me. This could be a graphics ‘driver’ issue. Make sure your OS is able to run accelerated graphics at all. Or maybe you’re running a sandbox of some kind.

For example to run in a Docker container locally, I needed to pass on:

The DISPLAY=${DISPLAY} environment.
Bind mount the /tmp/.X11-unix directory.
And using xhost to disable access control for remote sessions.

When not sandboxing anything you might look into troubleshooting GL issues in general with your OS. Try the good old glxgears, look around in journalctl/dmesg for graphical errors.

Beanow on Jul 11, 2022

The bug is still here with the 1.0.1 release.

yanganto on Jun 30, 2022

I ran into the same issue as @yanganto explains.

My setup:

Environment › OS: NixOS 21.11.0 X64 › Node.js: 16.15.1 › npm: 8.11.0 › pnpm: Not installed! › yarn: Not installed! › rustup: 1.24.3 › rustc: 1.61.0 › cargo: 1.61.0 › Rust toolchain: stable-x86_64-unknown-linux-gnu

Packages › @tauri-apps/cli [NPM]: 1.0.0 › @tauri-apps/api [NPM]: 1.0.0 › tauri [RUST]: 1.0.0, › tauri-build [RUST]: 1.0.0, › tao [RUST]: 0.11.2, › wry [RUST]: 0.18.3,

App › build-type: bundle › CSP: unset › distDir: …/build › devPath: http://localhost:3000/ › framework: React

App directory structure ├─ .git ├─ public ├─ src-tauri ├─ src └─ node_modules

Softsapiens on Jun 16, 2022

If I run cargo tauri dev, wait for it to show up, close the app and then immediately execute that command again, it should not take that long then, should it? But it does! 😢

i think there were 1 or 2 people who reported a similar problem, where using tauri + yew caused one of them to always recompile from scratch (iirc yew) even though the build files should be in different target dirs.

FabianLars on Nov 27, 2022