fix(windows): make auto-paste actually restore the target window - #269
Merged
Conversation
On Windows, simulate_paste hid QlipLab's own window and then called a bare SetForegroundWindow on the previously-focused window. By that point QlipLab is no longer the foreground process, so Windows' foreground lock denies the call and merely flashes the taskbar button — the synthesized Ctrl+V then lands nowhere, making paste look broken. Add restore_foreground_window(), which brings the target back reliably the way Ditto does: - IsWindow guard against a stale handle - SW_RESTORE if the target was minimized - AllowSetForegroundWindow + AttachThreadInput to both the outgoing foreground thread and the target's thread, so the foreground-lock check treats the request as cooperating - verify via GetForegroundWindow and retry once, then settle before Ctrl+V macOS/Linux paths are unchanged. Win32 signatures verified against windows 0.61.3 (AttachThreadInput lives in Win32::System::Threading, already enabled — no new crate feature needed). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
On Windows, paste often lands nowhere — the headline reason the app "feels broken" there.
simulate_pastehides QlipLab's own window and then calls a bareSetForegroundWindowon the previously-focused window. But by that point QlipLab is no longer the foreground process, so Windows' foreground lock denies the call and merely flashes the taskbar button. The synthesizedCtrl+Vthen goes to whatever the OS happened to leave focused.The fix
New
restore_foreground_window()brings the target back reliably, the way Ditto does:IsWindowguard against a stale handleSW_RESTOREif the target was minimizedAllowSetForegroundWindow+AttachThreadInputto both the outgoing foreground thread and the target's thread, so the foreground-lock check treats the request as cooperating rather than a background grabGetForegroundWindow, retry once, then settle beforeCtrl+VmacOS and Linux paths are unchanged.
Verification
Win32 signatures checked against windows 0.61.3 source (
AttachThreadInputlives inWin32::System::Threading, already an enabled feature — noCargo.tomlchange needed). Fullcargo check --target x86_64-pc-windows-msvccan't run from macOS (theringC dep won't cross-compile without the Windows SDK), so the CI Windows job is the real compile gate, and runtime behavior needs a check on an actual Windows machine.🤖 Generated with Claude Code