Feature Request: Filter clipboard sync by active window title / foreground process, not just source application

[NelsonParkITAdmin]

Solution

I use Wispr Flow, a voice dictation tool that transcribes speech and pastes the result into the active application (in my case, Chrome). CrossPaste sees these clipboard events as originating from Chrome rather than Wispr Flow, so the existing per-app Source Control exclusion cannot filter them out without disabling Chrome entirely.

The fix would be to extend Source Control to support filtering by foreground window title or foreground process name at the time of the clipboard event:

• Ignore clipboard events where foreground window title contains "Wispr Flow"
• Ignore clipboard events where foreground process is wispr.exe

Environment: CrossPaste 2.1.5.2343, Windows 11

Alternatives

• Disabling Chrome in Source Control stops the Wispr Flow sync but also blocks all other Chrome clipboard activity — too heavy-handed.
• Disabling Sync Text globally also blocks manual "Sync To" pushes, so that is not a viable workaround either.

How important is this improvement for you?

Would be a major improvement

[guiyanakuang]

Thanks for the detailed report.

What's happening now

CrossPaste currently attributes a clipboard event to the foreground window at the moment the change is detected. On Windows this is GetForegroundWindow() (same idea on macOS/Linux — it reads the active window, not the app that wrote the clipboard).

Wispr Flow is a background dictation tool: it never takes foreground focus — it injects text while Chrome stays focused. So the foreground window genuinely is Chrome the whole time. This isn't a timing/race issue; the "foreground window" signal simply can't answer "which process wrote the clipboard." That's why it shows up as Chrome.

How I plan to fix it

Windows exposes a more accurate signal for this: GetClipboardOwner(), which returns the window that last called SetClipboardData. Plan:

1. Resolve the source from GetClipboardOwner() (reusing the existing HWND → process → exe-description path).
2. Fall back to the current GetForegroundWindow() behavior when the owner is NULL (owner already exited, or a delayed-rendering clipboard).

If this works, Wispr Flow would be correctly identified as the source, and the existing per-app Source Control exclusion would just work — no new "filter by window title/process" setting needed.

I'll validate this locally and follow up.