Hotfix: input swallowing
If you were on 0.3.0-beta and noticed that typing in Chrome, Slack, Discord, or other Electron / Chromium-based apps sometimes felt like Cotabby was eating your keystrokes — this build fixes that.
What was happening
While a Cotabby suggestion was visible, the OS-level accept-key hook could swallow keystrokes that matched the user's accept binding. The match logic was correct in isolation, but two structural holes made it possible for ordinary typing to disappear:
- The key recorder accepted bare alphanumerics like a plain letter as an accept binding. From that moment, every press of that letter system-wide while a suggestion was visible got eaten.
- The default full-accept binding was bare backtick (`) — a real character users type in code, markdown, and JS template literals.
- The hook had no in-the-moment check that a real, ready suggestion existed when it consumed; any stale lifecycle state could leak into a swallow.
What changed
The active accept tap is now fail-open (#382). It refuses to consume a keystroke when either of the following is true:
- The bound key is a bare printable (no modifier + produces a unicode character). A warning lands in the runtime log pointing at Settings > Shortcuts.
- The coordinator does not confirm at event time that the suggestion state is
.ready, an active session is live, and the overlay is visible.
When in doubt, the keystroke falls through to the host app unchanged. The legitimate accept path is unchanged: with a modified binding (or plain Tab) and a real ready suggestion, acceptance still fires exactly as before.
Notes
- If you previously recorded a bare letter as your accept key, rebind it with a modifier in Settings > Shortcuts to restore acceptance. The fix means your typing comes through either way; the warning in the log is the only hint.
- 0.3.1-beta was skipped: it bundled a tighter AX-publish timing tweak that turned out to regress prediction quality. That change is reverted here in #384.
Full Changelog: v0.3.0-beta...v0.3.2-beta