fix: restore paste reliability on GNOME Wayland (terminals + GUI)

[christian-taillon]

Summary

• Skip native linux-fast-paste on GNOME Wayland (falls back to system tools which are more reliable in this environment).
• Add Shift+Insert fallback strategy when target window class cannot be detected (common on Wayland).
• Reorder tool priority for GNOME Wayland to prefer ydotool when available.

Why

On GNOME Wayland (e.g. Ubuntu 24.04), xdotool often returns null for the active window class, breaking terminal detection. This causes the app to send Ctrl+V to terminals (printing ^V) instead of Ctrl+Shift+V. Additionally, the native uinput binary reports success but often fails to deliver keystrokes to the focused window in this specific compositor environment.

Fix

1. Detect ambiguous GNOME Wayland state (isGnome && !xdotoolWindowClass).
2. Use Shift+Insert as a universal safe fallback chord (works in both terminals and GUI apps).
3. Ensure fallback tool chain is engaged by skipping the native binary in this specific case.

Validation

Verified locally on Debian Stable (GNOME Wayland):

• Paste works in gnome-terminal / console (using Shift+Insert fallback).
• Paste works in GUI apps (Text Editor, Chrome).
• Logs confirm fallback strategy is active and successful.

[christian-taillon]

Quick note: this still reproduces on v1.5.2 for me on Linux Wayland (GNOME) and is currently a hard failure (paste does not work).

Why this needs a fix:

• transcription succeeds, but auto-paste fails, so core dictation UX is broken on Wayland.
• current path can report success from linux-fast-paste --uinput even when no keys are delivered to the focused app.

I still think this direction is the right fix:

1. skip/de-prioritize linux-fast-paste on GNOME Wayland,
2. prefer ydotool / xdotool where applicable,
3. use Shift+Insert fallback when window class is unknown on Wayland.
   I have only validated this on GNOME Wayland so far; KDE/wlroots may need the same handling or compositor-specific logic.

[christian-taillon]

Follow-up fix pushed to this PR based on GNOME Wayland testing.

What changed:

• Use useShiftInsertFallback earlier in the Linux paste flow.
• If GNOME Wayland cannot detect an X11 window class, skip native linux-fast-paste and go straight to fallback tool selection (Shift+Insert path).
• This avoids a false-positive native "success" path where paste did not land in some Wayland-focused targets.

Validation notes:

• Tested on v1.5.3 with the PR patch applied.
• Local Whisper transcription succeeded.
• Paste now lands reliably in the previously failing Wayland scenario.

[christian-taillon]

Merged latest main into this branch and resolved the conflict in src/helpers/clipboard.js.

Conflict resolution keeps the GNOME Wayland reliability fix:

• use detectedWindowClass consistently
• compute useShiftInsertFallback before native fast-paste path
• skip native linux-fast-paste when GNOME Wayland window class is unavailable, then use fallback tool ordering/Shift+Insert path

This is the behavior validated on v1.5.3 during local testing.

[christian-taillon]

Hey @gabrielste1n

Don't easily have other Linux environments that aren't GNOME Wayland to test this in. It shouldn't modify behavior for other scenarios, but if you can point me to anyone who can test this small change or review it, it is the last change I need to make for my self to get the intended experience.

Loving the recent QoL for Linux users.

I hope this idea helps and no worries if you want to take it in a different direction.

[gabrielste1n]

@christian-taillon i'd love to see how we can make the linux-fast-paste binary the most robust solution - so instead of skipping it is there maybe something we can do to improve it? really appreciate your contributions

[christian-taillon]

@christian-taillon i'd love to see how we can make the linux-fast-paste binary the most robust solution - so instead of skipping it is there maybe something we can do to improve it? really appreciate your contributions

That desire makes sense. Let me look at it again. See if a modification can get it to work reliably. I had used ydotool in my own dictation solution before finding OpenWhispr to handle Wayland security quirks.

[christian-taillon]

I spent some time trying the linux-fast-paste primary-path approach on GNOME Wayland.

I added --shift-insert support in linux-fast-paste and routed the GNOME Wayland unknown-window-class case through the binary (--uinput --shift-insert) instead of skipping to external tools.

In my testing (terminal, desktop editor app, browser), that path still didn’t actually paste text.

What did work in the same environment was the existing ydotool Shift+Insert fallback.
At this point, ydotool’s approach seems like the only reliable way I can find to make this work on my setup. The fallback logic is only a few lines for me to maintain, so I’m okay keeping updated myself - I get why it isn't optimal.

If others aren’t seeing this issue on their Wayland systems, that’s useful context too. Maybe it isn't Wayland security/compositor issue. Logs show successful paste but no content pasted.

[christian-taillon]

Linking related threads so we can track Linux auto-paste behavior in one place:

• Original ydotool discussion/workaround: Linux GNOME Wayland paste reliability improvements #292
• Similar report/approach: Setup Guide for Ubuntu 24.04 LTS #310
• Current implementation attempt (PR): fix: restore paste reliability on GNOME Wayland (terminals + GUI) #293

Context: PR #293 currently relies on ydotool as an external dependency. That works as a workaround, but maintainers (and I agree) would prefer to keep this self-contained via linux-fast-paste instead of requiring extra system setup.

For clarity: I'm not suggesting this should be merged as-is for maintainers. I'm applying the PR #293 patch locally on top of the latest maintainer release so I can use ydotool as a temporary workaround in my own setup.

My current theory is this is largely Wayland security related: on Wayland, apps can't globally inject keyboard input the way X11 tools can, so approaches like xdotool often fail for native Wayland windows. linux-fast-paste may hit the same compositor/input-permission boundaries depending on session/compositor setup, while ydotool works in some cases because it injects via kernel/uinput (with additional system requirements).

Goal is still to get linux-fast-paste working reliably across Linux/Wayland setups so ydotool can remain optional (or unnecessary).

If anyone has findings on why linux-fast-paste fails in their environment (compositor/session/tooling), please share details here so we can converge on a native fix.