Chat bubble input never receives keyboard focus on KDE Plasma/X11 (v4.0.0)

[alfiyansys]

Environment

• OpenPets version: v4.0.0 (Linux .deb)
• Desktop: KDE Plasma, X11 session
• Dual monitor setup: 2x 1920x1080 @ 100% scale (no fractional scaling), one monitor at x=0, the other at x=1920

Bug

Clicking into the pet's chat bubble message input ("Message your pet...") does not transfer real keyboard focus to the OpenPets window. Anything typed afterward goes to whatever window previously held focus (e.g. a terminal) instead of appearing in the chat input.

Steps to reproduce

1. Open the pet's chat bubble (tried both the small "compact" popup and the full expanded chat window).
2. Click directly into the message input field.
3. Type text.
4. Nothing appears in the input; keystrokes land in the previously-focused window instead.

Diagnostics performed

• Confirmed with xdotool getwindowfocus, polled continuously (~every 0.4s) while clicking the input: real X11 keyboard focus never transfers to the OpenPets window at any point.
• OpenPets' own openpets.log shows focus policy applied ... focusable=true hasInteractiveInput=true being set correctly when the chat opens/expands, but this internal state does not correspond to actual X11 input focus.
• The pet/chat window never appears in the Alt+Tab task switcher (skipTaskbar: true), and clicking it produces no visible reaction at all (no highlight, no raise/bring-to-front).
• Ruled out KDE's "Focus stealing prevention" setting (tested with it set to None — no change).
• Ruled out window position relative to the monitor boundary (moved the window fully onto one monitor, away from the x=1920 seam — no change).
• Ruled out display scaling mismatch (both monitors at 100%, QT_AUTO_SCREEN_SCALE_FACTOR=0).
• Ruled out input-method issues (ibus is running normally).

Root cause hypothesis (from source)

In apps/desktop/src/wayland-backend.ts:

export function shouldPetWindowBeFocusable(
  platform: NodeJS.Platform | string,
  _effectiveWaylandBackend: boolean,
  hasInteractiveInput = false,
): boolean {
  if (hasInteractiveInput) return true;
  return platform !== "linux";
}

On Linux this returns false at window-creation time (no interactive input yet), so pet-window.ts's createBasePetWindowWithMode() constructs the BrowserWindow with focusable: false baked into the initial X11 window hints:

const focusable = shouldPetWindowBeFocusable(process.platform, effectiveWaylandBackend, focusOptions.hasInteractiveInput === true);
const window = new BrowserWindow({
  ...
  focusable,
  ...
});

When the chat bubble opens, applyPetWindowFocusPolicy() (pet-window.ts) and setCarrierMode() (default-pet-chat.ts) call window.setFocusable(true) + window.focus() on the already-mapped window to flip it back to focusable.

This looks like the bug: on X11 (observed here on KDE/KWin), a window created with focusable: false gets WM_HINTS.input = False at map time. Electron's setFocusable(true) afterward updates the property, but some window managers (KWin apparently included) don't re-evaluate focus-acceptance for a window that already told them "no input" once mapped — so window.focus() becomes a no-op even though Electron's own internal state (and the app's debug log) reports success. That matches exactly what I observed: the log always claims focus was granted, but xdotool getwindowfocus shows it never actually was.

There is also a smaller ordering race in setCarrierMode() (default-pet-chat.ts):

if (nextSize && !previousSize) {
  window.setBounds(nextBounds, false);
  window.setFocusable(true);
  window.focus();   // fires before the Linux input-shape is widened
}
...
if (isExpanded) {
  window.setFocusable(true);
  window.focus();
}

void import("./pet-window.js").then(({ applyLinuxPetWindowShapeWithExpansion, refreshDefaultPetFocusPolicy }) => {
  applyLinuxPetWindowShapeWithExpansion(window, isExpanded, compactIsOpen, activeChatPanelHeight);
  refreshDefaultPetFocusPolicy(window);
}).catch(() => {});

focus() runs synchronously, but the X11 setShape() call that widens the window's clickable/input region to cover the new chat panel only happens afterward, inside a dynamically-imported async callback. If the WM validates a focus/activate request against the window's current input region, this ordering could independently drop the focus grab even if the "created non-focusable" issue above were fixed.

Suggested fix

1. Always create the Linux pet window with focusable: true, and rely solely on setShape() (already used for hit-testing) to make the idle/passive pet area click-through, instead of also toggling the OS-level focusable flag. This avoids ever asking KWin (or other WMs with the same caching behavior) to revive focus-acceptance on an already-mapped window. shouldPetWindowBeFocusable could simply return true for X11; Wayland/layer-shell backends already avoid focus through a separate path (isLayerShellBackendRequested) and would be unaffected.
2. If non-focusable-at-creation needs to stay (e.g. for Wayland compositors like Niri, per the comment above shouldPetWindowBeFocusable), at least fix the ordering in setCarrierMode(): hoist the dynamic import("./pet-window.js") to a static import and apply applyLinuxPetWindowShapeWithExpansion() before calling window.setFocusable(true) / window.focus(), so the WM sees the final input region before the focus request arrives.
3. Add a regression check that verifies real WM-level focus transfer on Linux (e.g. via xdotool getwindowfocus in manual QA or CI under X11), not just Electron's own isFocusable()/internal flag — the current debug logging only reflects Electron's belief, which is how this class of bug can ship silently.

I'm happy to send a PR for this if useful — will follow up.

[pinoybear]

Hi @alfiyansys, thanks for this fix. Chat input works for me on KDE Plasma/X11 now. I did run into a side effect of #228, though: with the pet window focusable, KWin manages it like a normal window, so it now shows up in the taskbar and Alt+Tab, and closing it from the taskbar destroys the pet. It happens even with the chat button off.

I wrote up the details, what I tried, and a KDE workaround in #233. I'd love your thoughts on a fix that keeps chat input working.

[alfiyansys]

Hi @pinoybear, thanks for the thorough follow-up (and for #233, that's a great writeup).

You're right that #228 traded one bug for another. On reflection, the fact that focusable: false was the only thing keeping the pet unmanaged (since skipTaskbar never worked on Linux to begin with) wasn't something I checked for. I was focused on getting real keyboard focus working and verified that narrowly, I'm sorry for this.

Of your proposed directions, recreating the window when entering/leaving a focus-needing state (your option 1) I think it looks promising, mainly because it doesn't fight KWin: we already know from #227 that WM-level focus/managed-state is decided at map time, not mutable at runtime, so a fresh window created focusable: true only while chat/plugin input is actually open and recreated focusable: false when it closes should get KWin to treat it as unmanaged again the rest of the time. It's also not a new pattern for this codebase: pet-window.ts already does a very similar destroy-and-rebuild-at-tracked-position dance for the layer-shell fallback path, so the state-transfer plumbing (position, sprite/reaction state) has precedent to lean on.

Let's wait and see what @alvinunreal thinks on #233.

[alvinunreal]

I’m investigating this alongside #233. In the KDE/X11 test VM, the focusable default pet is managed as a normal window and lacks the X11 skip-taskbar/pager states; requesting those states manually updates the window as expected. I’m working on keeping the pet focusable from creation for chat/plugin input while requesting taskbar, pager, and KDE switcher exclusion before its first show, rather than rebuilding the pet whenever input opens. I’m also changing window-manager close to temporarily hide the default pet instead of destroying it. Next I’ll verify the actual taskbar/Alt+Tab behavior and real keyboard focus in KDE and GNOME, including a packaged build. This is investigation and implementation in progress, not a verified or released fix yet; I’ll follow up on #233 with the results.

[alfiyansys]

Thanks @alvinunreal, that sounds like a great approach! Looking forward to trying it once it's ready. I'll keep an eye on #233 for the update.

[alvinunreal]

@pinoybear @alfiyansys I opened PR #234 for the regression discussed here and in #233. The pet stays focusable from creation, so chat/plugin input does not require rebuilding its window; X11/XWayland taskbar, pager, and supported KDE switcher exclusions are requested across the actual map transition. Window-manager close now temporarily hides the default pet, and tray Show restores the same window without changing its launch preference.

On a packaged KDE/X11 VM I verified the pet is absent from the visible Alt+Tab switcher, chat accepts real typing, and WM close → tray Show works. Packaged GNOME/Wayland reaches XWayland with the standard skip states, but a keyring modal blocked a reliable GNOME GUI Alt+Tab/typing check. This is a PR ready for review, not a merged or released fix yet. If you can try it on Plasma 6.7.5, that would cover a newer KWin than my VM.

[alvinunreal]

@pinoybear @alfiyansys Follow-up on PR #234: we cleared the GNOME VM first-run/keyring dialogs and completed the GUI checks. The visible pet was absent from a captured GNOME Alt+Tab switcher listing Files and Terminal, and typed text appeared in the pet chat field. KDE checks remain passing. This updates the GNOME limitation in my earlier comment; the PR is still awaiting review/merge.

[alvinunreal]

@pinoybear @alfiyansys Update: the separate Linux-only rebuild was superseded and removed. The fixed Linux packages are now the four Linux downloads on the main OpenPets v4.0.0 release. The x86-64 AppImage now has SHA-256 4080c06327fc7a4d9fcd5475848db0df6ff43f7bb807955046321b231204e56f. Manually reinstall/replace your Linux 4.0.0 package; the unchanged version will not trigger an update notice. PR #234 is merged, and main-branch x86-64 CI passed. If you try Plasma 6.7.5, please report whether Alt+Tab and chat typing both behave as expected.

[alvinunreal]

@pinoybear @alfiyansys The fix is now merged (#234), and the Linux AppImage/DEB/RPM/tar.gz on the main v4.0.0 release have been replaced with the verified builds. Please manually reinstall/replace your Linux package; the app still reports 4.0.0, so it will not appear as an automatic update. The earlier separate-rebuild link has been removed. The new x86-64 AppImage has SHA-256 4080c06327fc7a4d9fcd5475848db0df6ff43f7bb807955046321b231204e56f. Ubuntu x86-64 CI passed package validation and installed-DEB X11 startup/WM-close checks; KDE and GNOME VM switcher/typing checks passed on arm64. Feedback from Plasma 6.7.5 would still be useful.