Stop mute and deafen firing the moment they are assigned

[greluc]

Replaces #407, which was opened from a fork I have retired. Same branch, same commits, nothing rewritten — reopened from the fork I now work out of. #407 is closed.

The branch is merged up to current nightly. #404 and #405 reworked these same handlers and fixed half of what #407 originally claimed; the description below is the corrected, narrower one.

Assigning the mute or deafen shortcut fires it immediately.

Why

node-keyboard-watcher polls. AddKeyHandler seeds a key as up, and the thread compares that seed against GetAsyncKeyState every 60 ms, emitting a transition:

void AddKeyHandler(int keyId) {
	if (key_map.count(keyId) == 0)
		key_map.insert(std::pair<int, keystate>(keyId, keystate::Up));
}
void ClearKeyHooks() { key_map.clear(); }

KeybindsSection commits a binding on onKeyDown, while the key is still held, and setShortcut sends RESET_KEYHOOKS in the same tick. resetKeyHooks wipes the map, so the key the player is holding is re-seeded up — and the next sweep reports a keydown nobody made. The real release then completes a press the app invented, and the toggle fires.

What is already fixed, and not by this PR

releaseHeldKeys() from #404/#405 lets go of whatever was held before the hooks are rebuilt, which removes the stranded-microphone class entirely. Measured with the harness below: over 20 000 random gestures that end by releasing everything and settling, the pre-#404 code left the microphone open in 54 runs and current nightly in none. That half is yours, and this PR keeps it.

What is left

Two changes.

resetKeyHooks no longer calls clearKeyHooks. Wiping the map is what fabricates the press. addKeyHook ignores a key already in the map, so re-applying the shortcuts leaves every key exactly as the watcher last saw it. The cost: a key that stops being a shortcut keeps being polled until exit — it matches no binding, so nothing acts on it. The addon has no way to unhook one key (RemoveKeyHandler is empty), which is why this wiped everything.

The toggles are answered from what the key was granted when it went down, rather than from the bindings as they stand at keyup. A binding can be reassigned to the very key being held — which is precisely what assigning one of these shortcuts does, and it is why the release of the assigning press would otherwise fire the shortcut it had just created.

And the settings field commits on the DOM keyup instead of the keydown. The renderer is the only part of the app that knows the key is up; the main process cannot ask. Hooking it in a state the watcher agrees with is the point.

Verification

The watcher was modelled from keyhandler.cpp — seed-up-on-add, clear-on-reset, edge-triggered emission on a 60 ms sweep — and used to drive the real handler bodies extracted from hook.ts, so the same script runs against either revision.

	nightly	this branch
S1 assigning mute must not fire it	FAIL MUTE	ok
S2 assigning over the push-to-talk key	FAIL MUTE	ok
S3 ordinary push-to-talk	ok	ok
S4 pressing mute later	ok	ok
S5 unrelated reset while push-to-talk held	ok	ok
S6 impostor radio across the end of a round	ok	ok
S7 released before the next sweep	ok	ok
S8 rebinding away from a held key	ok	ok
20 000 random gestures, settled	ok, 0 open	ok, 0 open

Only the two rows this PR is about change. npm run typecheck, eslint and prettier --check are clean.

What changes for a user

Holding a key over the field and clicking away without releasing it now binds nothing, where before it bound the key and fired the shortcut. The binding is recorded on release rather than on press, so the field updates a few tens of milliseconds later.

A key unbound while still held will still toggle on release, because its press was granted. Same rule as everything else here, and it cannot leave anything held.

Limits, stated plainly

The watcher model is my transcription of keyhandler.cpp, not the C++ itself, and nothing ran against a real keyboard or a built addon — this is Windows-only native code. emit_event uses a ThreadSafeFunction NonBlockingCall, so delivery to the main thread is asynchronous while my model delivers synchronously per sweep. I do not believe that can reorder a keydown after its own keyup, but I have not proved it.

The harness is not in this PR — there is no test runner here and adding one does not belong in a bug fix. Happy to contribute it separately.

Disclaimer

This change was written with AI assistance (Claude Code). The author reviewed it, and every claim was checked against the actual sources — including reading the addon's C++ — with behaviour produced by running code rather than reasoned about. Several earlier designs were discarded because testing showed they reintroduced a stuck microphone by another route. Please review it as you would any patch from a stranger; if something here is wrong I would rather hear it than have it merged.

🤖 Generated with Claude Code

[github-actions]

Download the artifacts for this pull request:

• BetterCrewLink Unpacked 64bit.zip
• BetterCrewLink Installer Windows.zip
• BetterCrewLink Installer Linux.zip

---

This service is provided by nightly.link. These artifacts will expire in 90 days and will not be available for download after that time.