[bug] Could not determine the accessibility bus address

Elanis commented 2 years ago

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

Elanis commented 2 years ago

I tried adding at-spi2-core with apt in addition to the recommended tauri packages, based on Google search, but same result

lucasfernog commented 2 years ago

Might be worth looking into how we run our own benchmarks: https://github.com/tauri-apps/tauri/blob/8a63489567b9fa86e404ad42b5b30c64361efe85/.github/workflows/bench.yml#L107

Regarding the issue itself, i've never seen it :/

Elanis commented 2 years ago

Oh, didn't see you had your own benchmark, will look into it ! Thanks ;)

lucasfernog commented 2 years ago

You can see the results here: https://tauri.studio/about/benchmarks

Elanis commented 2 years ago

Amazing, thanks !

Elanis commented 2 years ago

Update: I still have this error in stderr but it looks like it runs fine. I guess it's the same kind of problem I have with other frameworks (e. g. Electron) when they have problems when calling unix sockets. Will investigate on it in the future, but it's non-blocking atm.

Thanks for your help ;)

yanganto commented 2 years ago

@lucasfernog I ran into this issue. I got this message, Could not determine the accessibility bus address, with cargo run. And the window show without content inside (But it is loaded and the HTML source can be inspected). Tauri

Also, I try xvfb-run --auto-servernum cargo run, but the window does not show, and there was more error message.

Could not determine the accessibility bus address
Cannot get default EGL display: EGL_SUCCESS
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)

Elanis commented 2 years ago

I didn't have those following error message on my CI, but might be linked indeed

Softsapiens commented 2 years ago

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

yanganto commented 2 years ago

I also use NixOS.

yanganto commented 2 years ago

The bug is still here with the 1.0.1 release.

Beanow commented 2 years ago

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.

aveltras commented 2 years ago

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.

yanganto commented 2 years ago

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

matthiasbeyer commented 1 year ago

I am running into this issue as well. Problem is also that my app takes about 2 minutes before it shows a GUI. The application itself is not more than a hello-world (from here).

It shows the following error output:

Could not determine the accessibility bus address

(process:1224071): GLib-GIO-CRITICAL **: 09:31:31.245: g_task_get_cancellable: assertion 'G_IS_TASK (task)' failed

(process:1224071): GLib-GIO-CRITICAL **: 09:31:31.245: g_task_get_cancellable: assertion 'G_IS_TASK (task)' failed

(process:1224071): GLib-GIO-CRITICAL **: 09:31:31.497: g_task_get_cancellable: assertion 'G_IS_TASK (task)' failed
                                                                                                                                                                                                       (process:1224071): GLib-GIO-CRITICAL **: 09:31:31.752: g_task_get_cancellable: assertion 'G_IS_TASK (task)' failed

Once the app is shown, saving a file and letting cargo tauri dev re-start the GUI works fast and as expected.

Beanow commented 1 year ago

@matthiasbeyer Could not determine the accessibility bus address is a warning and shouldn't be related to slower startup time.

Once the app is shown, saving a file and letting cargo tauri dev re-start the GUI works fast and as expected.

This sounds like the dev environment was still compiling. This is common during development, but shouldn't be an issue when you make production builds.

The application itself is not more than a hello-world (from here).

Keep in mind this guide is close to a year old and uses an unsupported Tauri beta release (before it's first stable release). Using create-tauri-app also has a Yew template for you :smile:. https://tauri.app/v1/guides/getting-started/setup/

matthiasbeyer commented 1 year ago

Once the app is shown, saving a file and letting cargo tauri dev re-start the GUI works fast and as expected.

This sounds like the dev environment was still compiling. This is common during development, but shouldn't be an issue when you make production builds.

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! 😢

The application itself is not more than a hello-world (from here).

Keep in mind this guide is close to a year old and uses an unsupported Tauri beta release (before it's first stable release).

Ah, yes sorry for being not specific about this. I updated all dependencies to the latest version and did not follow the guide 1-1.

FabianLars commented 1 year ago

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.

matthiasbeyer commented 1 year ago

I think I have to disagree... If there would be some recompilation I would see this in htop. But there's nothing there... just my firefox using a bit of CPU power... Also, the delay between me issuing the cargo tauri dev command and the window popping up is way bigger than the recompilation would take... in the meantime I could recompile my whole codebase from scratch on this machine!

matthiasbeyer commented 1 year ago

Any updates on this?

cargo-tauri-dev is still unbearably slow for me. (FWIW: My frontend code is not yew anymore, but I think this hasn't anything to do with this issue...)

FabianLars commented 1 year ago

@matthiasbeyer Still weren't able to reproduce it, and didn't hear of anyone else with the same issue/delay (other than something similar we're seeing in our benchmark CI, which we also weren't able to reproduce). Therefore it's really hard to find the issue.

Also, this is not related, or should not be related, to the accessibility bus warning so you probably should file a separate issue for this please.

matthiasbeyer commented 1 year ago

this is not related [...] to the accessibility bus warning so you probably should file a separate issue for this please.

Yep, I'm gonna do that.

agracey commented 1 year ago

I'm running into the same issue (or similar) when building an app in a docker container then running it in a kubernetes pod with X11 along side. This same setup has worked with firefox and chromium so I know the underlying X11 portion is correct.

I'm using the create-tauri-app template and, when I start the container, I get "Could not determine the accessibility bus address" in stdout/stderr along with a blank fullscreen app.

Edit: just tested with fullscreen being false and I see a titlebar with the window still being blank.

Edit 2: just tested with running cargo tauri dev both in and out of docker and the same source works outside of docker. What I think is strange is that the window shows up just fine, it’s just empty

j-a-m-l commented 1 year ago

Thank you @aveltras.

As NixOS user WEBKIT_DISABLE_COMPOSITING_MODE=1 solved my problem.

tauri-apps / tauri