Describe the bug
On Windows 0.0.9 with clipboard_free insertion, when direct insertion is unavailable the app falls back to typing the transcript via SendInput Unicode input. Those synthetic keystrokes combine with whatever modifier keys are physically held at insertion time. With a modifier-based shortcut (Ctrl+Win) in hold activation mode, transcription of a longer dictation completes 1–4 s after release — and if the user has pressed Ctrl again in that gap (most commonly: already holding Ctrl+Win to start the next dictation), the target app interprets the typed characters as shortcuts. The visible result: the sentence never appears, and if the transcript contains a "v" the target receives Ctrl+V and pastes the previous clipboard contents. To the user this looks like "FluidVoice typed nothing" or "FluidVoice pasted my old clipboard."
The typed output should be deferred until all physical modifier keys are up (or modifiers should be neutralized/masked for the duration of the synthetic input).
Reproduction steps
- Windows 0.0.9, shortcut Ctrl+Win, activation mode
hold, insertion mode clipboard_free, focus an app that takes the typed-input fallback path (log shows "Typed text with clipboard-free Unicode input fallback").
- Copy some text to the clipboard (to make the failure visible).
- Hold Ctrl+Win and dictate a longer passage (30+ words so CPU transcription takes a few seconds), release.
- Immediately hold Ctrl+Win again (as if starting the next dictation) and keep holding through the moment the previous transcript is inserted.
- Observe the previous dictation's text: it does not appear; if it contained a "v", the old clipboard content is pasted instead.
Expected behavior
The transcript is inserted as plain text regardless of which modifier keys the user is physically holding when insertion fires.
Actual behavior
Typed Unicode input merges with held modifiers, so characters become accelerator shortcuts in the target app. Log for a normal (successful) case shows insertion fires ~340 ms after the last modifier-up, with no guard against modifiers being re-pressed:
01:06:58.517 [DIAG] Shortcut hook modifier event: vk=91, event=up
01:06:58.539 [DIAG] Shortcut hook modifier event: vk=162, event=up
01:06:58.540 [INFO] Activation event: pressed=false, mode=hold, release_triggered=true
01:06:58.875 [INFO] Preparing text insertion: chars=60, mode=typed, target=0x13c1666
01:06:58.920 [INFO] Sent Unicode text input: units=60, chunks=1
01:06:58.920 [INFO] Typed text with clipboard-free Unicode input fallback: focus_ms=0, total_ms=45
For a 93-word dictation, transcribe_ms was 3,583 on CPU — a multi-second window in which re-pressing the hold shortcut corrupts the pending insertion. Hold mode makes this near-inevitable during rapid back-to-back dictation.
App Version
Windows 0.0.9 (windows-v0.0.9)
Environment
- Windows 11 Pro 10.0.26200, x64
- Shortcut: Ctrl+Win, activation mode hold, insertion mode clipboard_free (typed-input fallback path)
- ASR: Parakeet TDT 0.6b v3 q8 (parakeet.cpp), CPU
Notes
(Reported with the help of Claude, which diagnosed this from fluidvoice.log on the affected machine.)
Describe the bug
On Windows 0.0.9 with
clipboard_freeinsertion, when direct insertion is unavailable the app falls back to typing the transcript via SendInput Unicode input. Those synthetic keystrokes combine with whatever modifier keys are physically held at insertion time. With a modifier-based shortcut (Ctrl+Win) in hold activation mode, transcription of a longer dictation completes 1–4 s after release — and if the user has pressed Ctrl again in that gap (most commonly: already holding Ctrl+Win to start the next dictation), the target app interprets the typed characters as shortcuts. The visible result: the sentence never appears, and if the transcript contains a "v" the target receives Ctrl+V and pastes the previous clipboard contents. To the user this looks like "FluidVoice typed nothing" or "FluidVoice pasted my old clipboard."The typed output should be deferred until all physical modifier keys are up (or modifiers should be neutralized/masked for the duration of the synthetic input).
Reproduction steps
hold, insertion modeclipboard_free, focus an app that takes the typed-input fallback path (log shows "Typed text with clipboard-free Unicode input fallback").Expected behavior
The transcript is inserted as plain text regardless of which modifier keys the user is physically holding when insertion fires.
Actual behavior
Typed Unicode input merges with held modifiers, so characters become accelerator shortcuts in the target app. Log for a normal (successful) case shows insertion fires ~340 ms after the last modifier-up, with no guard against modifiers being re-pressed:
For a 93-word dictation,
transcribe_mswas 3,583 on CPU — a multi-second window in which re-pressing the hold shortcut corrupts the pending insertion. Hold mode makes this near-inevitable during rapid back-to-back dictation.App Version
Windows 0.0.9 (windows-v0.0.9)
Environment
Notes
insertedmode issue where the fixed 650 ms clipboard-restore also raced slow targets and pasted stale clipboard content; both paths lack synchronization with real-world input state at insertion time.(Reported with the help of Claude, which diagnosed this from fluidvoice.log on the affected machine.)