tao
tao copied to clipboard
[bug] Global shortcuts are never triggered on Linux
Describe the bug
Even using API example it's possible to register global shortcut, but it never triggers on linux This line never reached.
Reproduction
Compile latest tauri (git commit 46f2eae8aad7c6a228eaf48480d5603dae6454b4) and run api example as per readme. Observe lack of global shortcut trigger - both JS and Rust examples don't work.
Expected behavior
Shortcut triggered - from JS and Rust
Platform and versions
Operating System - Pop!_OS, version 20.04 X64
Stack trace
No response
Additional context
No response
For me this is a major blocker to ship tiny Tauri app, let me know if I can help to debug or progress this bug. I can confirm shortcut trigger works on Mac and doesn't work on Linux (Pop OS 20.04).
Please give us more information. What window compositor are you using? What does tauri info tell you? Have you tried on any other Linux distros?
tauri info (from next branch)
yarn tauri info
yarn run v1.22.17
warning package.json: No license field
warning ../../../../package.json: No license field
$ node ../../tooling/cli.js/bin/tauri info
app:spawn [sync] Running "cargo build --release" +0ms
Compiling tauri-cli v1.0.0-beta.7 (/home/alex/rust_code/tauri/tooling/cli.rs)
Finished release [optimized] target(s) in 9.95s
app:spawn Running "/home/alex/rust_code/tauri/tooling/cli.rs/target/release/cargo-tauri tauri info" +10s
Operating System - Pop!_OS, version 20.04 X64
Node.js environment
Node.js - 14.17.0
@tauri-apps/cli - 1.0.0-beta.10
@tauri-apps/api - 1.0.0-beta.8
Global packages
npm - 8.3.1
pnpm - 6.24.4
yarn - 1.22.17
Rust environment
rustc - 1.58.0
cargo - 1.58.0
Rust environment
rustup - 1.24.3
rustc - 1.58.0
cargo - 1.58.0
toolchain - stable-x86_64-unknown-linux-gnu (default)
App directory structure
/src
/node_modules
/src-tauri
/dist
/public
App
tauri.rs - 1.0.0-beta.8
build-type - bundle
CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: asset: customprotocol: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
distDir - ../dist
devPath - http://localhost:5000/
framework - Svelte
Pop!_OS 20.04 LTS (with Nvidia drivers) gdm, GNOME 3.36.8, Xwindows/X11 What other information would be helpful? I don't have any other linux setup.
Strangely Ctrl-T/CTRL+D for test/disable submenu works. Global shortcut only registered but never triggers.
ok, we need to try to replicate this. thanks for the insight!
@nothingismagick let me know if I can help debug it further - I don't mind running tauri under gdb or anything which will produce useful logs for you.
cheers. am going to ask @wusyong to have a look and see if he can replicate.
I have tried it on a clean install of pop os 20.04 and on 21.04, the issue is persistent.
I also plan to revision our global handler since it's still only available on x11. We should use Gtk's accelerator group already.
Hurrah! I am going to test tonight.
I think that broke now register in JS, if I run example/api and try to register global shortcut I get an empty array in Tauri console (screenshot) and error in JS console:
[Error] Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating 'window.rpc.notify')
promiseEmptyOnRejected (chunk-KSXZ7OFV.js:136)
promiseReactionJob

api git:(next) ✗ cargo tree | grep tao
│ ├── tao v0.6.1
➜ api git:(next) ✗
@AlexMikhalev i think you need to re-build the api package (cd tooling/api && yarn && yarn build). This is unrelated to this tao change tho, and caused by the huge audit changes.
I rebuild before reporting the bug. I also rebuild it following the advice above, but global shortcuts are not triggered or registering now. Promise rejection is at the start of the Tauri app, that's not related to the bug above.
@AlexMikhalev the promise rejection error is as stated by Fabian because of outdated api package. Please wait for the new release which should be so soon or test the globalShortcut functionality using tao directly, you can find an example in the examples directory in tao repo.
@amrbashir ok, waiting for the new release of Tauri with bugfix. This probably means the bug isn't closed yet.
@AlexMikhalev We released the first rc version yesterday 🥳
We are looking for help! I couldn't reproduce this in my PC, laptop and even VM. But there are still people have this issue. On x11, we listen XNextEvent here. And according to people that has trouble, XPending is always 0 for some reason despite they already typed several different keys. And on wayland, we simply haven't done it yet. Contribution is welcome!
What does "global" shortcut mean? Wayland intentionally doesn't let you read keyboard events when your window is not focused.
Yeah, you are right. I forgot to mention tauri-apps/global-hotkey#28 too. wayland-protocols has an RFC about this but doesn't seem pretty active recently.
For whatever reason github didn't save my message so i try my best to replicate it from memory 😅
Wayland intentionally doesn't let you read keyboard events
Yep we know that, but:
- global shortcut don't work for some users on x11 either (this is what this issue was about)
- the current implementation doesn't work for focused wayland windows either
- ~~if i remember correctly, we found a workaround to make global shortcuts work in a wayland session via winit's DeviceEvent::Key~~
if i remember correctly, we found a workaround to make global shortcuts work in a wayland session via winit's DeviceEvent::Key
That is not right, DeviceEvent::Key is not supported on wayland.
This issue should just focus on x11 and wait for wayland to implement a protocol for global device events.
Yeah you're right, just checked our convo again and I wasn't even able to spawn a winit window on Wayland back then (it still doesn't work and it's still crashing my system 😂)
but the device events were working correctly on (x11) systems where our current shortcut implementation doesn't work, so that's what I mixed up in my previous comment.
So, on Manjaro Gnome X11 neither tauri/examples/api nor cargo run --example=global_shortcut here seem to have working shortcuts.
That said, it's the first time I switched to X11 (over wayland) on this install. And it's had more shortcut issues as I've messed about with ibus/fcitx for IME's. I'll see if I can reproduce elsewhere.
Any particular aspects you want me to test?
So I tested on a manjaro live image, and shortcuts do work under Gnome X11, probably did bork something on the install.

Edit: I did try fcitx5 and even pipewire to be sure, like I use on the installed version. :shrug: just works. Even when focussed under wayland and global on X11.
On x11, we listen XNextEvent here. And according to people that has trouble, XPending is always 0 for some reason despite they already typed several different keys.
Like mentioned here, on the installed OS I also see this. XPending is always 0, and if I were to skip the XPending > 0 check XNextEvent blocks indefinitely.
Also strange, the Tauri API example defaults to Ctrl+X (which is cut by default), and plays the 'drip' alert sound when pressed. Like it tried and failed to cut. Which it didn't do when the binding was working properly.
I've not yet been able to find what caused it to break.
@AlexMikhalev do you still have this issue? If so can you check if toggling NumLock on and off makes any difference? shortcuts should trigger when it is off but will fail when is on, see tauri-apps/tao#537
For what it's worth, i can confirm that turning off numlock makes it work again. Took me some time to figure out that even tho my new keyboard doesn't have a numpad, num lock was still set to on (xset q | grep Caps), had to disable it via xdotool key Num_Lock
tauri-apps/tao#538 should fix this. If you want to test the fix, add this to your Cargo.toml and then run cargo update -p tao in src-tauri
Edit: the fix is now part of the dev branch
[patch.crates-io]
tao = { git = "https://github.com/tauri-apps/tao", branch = "dev" }
Looks like the issue still exists but it definitely has something to do with NumLock On/Off state
Looks like this is a known X11 behavior, https://stackoverflow.com/questions/4037230/global-hotkey-with-x11-xlib.