lldb hangs 1-2s whenever I press Ctrl+key or Cmd+key for the first time on Mac (since winit v0.30)
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## Bevy version
Present on v0.14.0-rc.3, not present on v0.13.2. I've bissected this to commit 061bee7e3, which fixes #13366 "fix: upgrade to winit v0.30".
## \[Optional\] Relevant system information
Mac M1 Sonoma
## What you did
When I debug my app via vscode (which uses lldb), I noticed that the first time I press Ctrl+key or Cmd+key, my app always hangs for 1-2 seconds: the window does not respond, and the Bevy main loop hangs during this time. (Things like .just_pressed are also broken -- the key eventually gets "pressed" without ever triggering "just_pressed")
Things run normally
- on subsequent shortcut presses
- or when I run my app without debugging.
## What went wrong
I was expecting the app not to hang when I press shortcuts.
## Additional information
I used this to reproduce the bug:
```sh
cargo build --example empty_defaults && lldb -o run target/debug/examples/empty_defaults
```
This builds the empty defaults example (a simple empty window) and runs it with the lldb debugger. As soon as the window appears, I press a random Ctrl+key shortcut, e.g. Ctrl+L, and the following happens:
* Starting from 061bee7e3: I see lldb loading some Apple-specific symbol tables for 1-2 seconds, and the window hangs during this time
* Before 061bee7e3: lldb does not do the symbol table loading, and the app continues running without a hitch
I've bisected into winit, and this issue seems to have been introduced in https://github.com/rust-windowing/winit/pull/3231 , which adds the "Services menu" feature to the app on Mac.
Contributor guide
Research direction
Run `cargo build --example empty_defaults && lldb -o run target/debug/examples/empty_defaults` on macOS and reproduce the first Ctrl+key or Cmd+key shortcut hang. Compare the behavior before and after commit 061bee7e3, then inspect the winit PR #3231 Services menu change; done means the first shortcut no longer blocks the window or main loop.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100