Skip to content

fix(macos): let a fresh press finish a lock after a missed key release - #111

Open
AmadeusTwi wants to merge 1 commit into
anomalyco:mainfrom
AmadeusTwi:fix/locked-dictation-stale-key
Open

AmadeusTwi wants to merge 1 commit into
anomalyco:mainfrom
AmadeusTwi:fix/locked-dictation-stale-key

Conversation

@AmadeusTwi

@AmadeusTwi AmadeusTwi commented Sep 29, 2026 •

Copy link
Copy Markdown

HEX version

2.1.22, installed from the signed DMG

Platform

macOS

System details

macOS 15.8 (24H23), MacBook Pro M4 Pro, 24 GB

What happened?

About once every 5–10 dictations, a locked dictation stops responding to the shortcut. I press Right Option to finish and nothing happens, the HUD just keeps recording. The only way out is Escape, which throws the whole recording away. I've lost a few long dictations this way, the longest was about 7 minutes.

Expected: pressing the shortcut again finishes and transcribes, like it does the rest of the time.

Steps to reproduce

  1. Dictation shortcut: Right Option. Double-tap to lock on, Double-tap only off, Release microphone while idle on.
  2. Double-tap Right Option to lock and start talking.
  3. Keep using the keyboard in other apps while it's locked (typing, shortcuts, switching apps).
  4. Press Right Option to finish.

It's intermittent. Most locked sessions finish fine, and I can't trigger it on demand.

Additional context

Every time it got stuck, process.log shows this right after I hit Escape:

WARN voice_control::suppression: resynchronized stale input tracking after neutral keyboard key_count=1

My guess from reading suppression.rs: a key I pressed during the lock never gets its key-up, so it stays in pressed_keys, and a modifier-only shortcut only counts as pressed when that set is empty. Stale key recovery would clear it, but it only runs in Idle and Dirty, so it never runs during a lock. Escape switches to Dirty, recovery kicks in, and the shortcut works again, but by then the recording is gone.

This PR is my attempt at a fix: stale key recovery now also runs for a lock that tracks a held key. It clears the key bookkeeping and keeps the lock, so the next shortcut press finishes normally. The regression test locked_dictation_finishes_after_a_missing_key_release fails on main and passes here. cargo fmt --check, cargo test, cargo clippy --all-targets --all-features -- -D warnings and git diff --check all pass locally (Xcode 26.3, macOS 15.8). I haven't tried it in a signed build yet.

Currently I am running local build with this fix, will report back maybe in a day if it truly fixed my issues.

Update on Oct 1st: Yep, it was a smooth experience for me after I added this fix in. I would greatly appreciate if this is added so I don't have to rebuild all future versions on my own.

Heads-up: I don't have real Rust knowledge, this fix was drafted by AI agent, so please take the diagnosis and the fix with a grain of salt. It was just frustrating enough that I had a go at it.

A double-tap lock captures while the keyboard sits idle, but stale key
recovery skipped Locked. If a key pressed during the lock lost its key-up,
pressed_keys stayed non-empty, the modifier-only trigger never registered,
and Escape (which discards the capture) was the only way out.

Run the existing neutral-keyboard recovery for a lock that tracks a held
key. It clears the key bookkeeping, keeps the lock, and emits no capture
action, so the next shortcut press finishes the dictation normally.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant