[kwin] [Bug 524422] New: wayland: Claude desktop rises window to top on focus

https://bugs.kde.org/show_bug.cgi?id=524422

            Bug ID: 524422
           Summary: wayland: Claude desktop rises window to top on focus
    Classification: Plasma
           Product: kwin
      Version First 6.7.4
       Reported In:
          Platform: Arch Linux
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: decorations
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

Title: "Focus follows mouse" auto-raises one specific application's window on
hover, unlike every other window

Component: kwin (Wayland session)

## Summary

With Focus Policy set to "Focus follows mouse" in a Plasma Wayland session, one
particular
application window (Claude Desktop, an Electron app) gets raised to the top of
the window
stack the moment it receives keyboard focus from a mouse hover — with no click
involved.
Every other window tested on the same session (Dolphin, Konsole, System
Settings, a native-Wayland
Chromium window) correctly keeps classic sloppy-focus behavior: hovering grants
keyboard focus
(visible via the active-window shadow) without changing stacking order. You
still have to click
a covered window to bring it to front — except for this one app, which raises
itself on hover alone.

## Environment

- KWin: 6.7.4
- Plasmashell: 6.7.4
- Kernel: 7.1.8-arch1-3 (Arch Linux)
- GPU/driver: AMD Radeon RX 7800 XT, amdgpu
- Session type: Wayland (confirmed via $XDG_SESSION_TYPE)
- Focus policy: FocusFollowsMouse (System Settings → Window Management → Window
Behavior → Focus)
- Reproducing app: Claude Desktop (Anthropic), Electron 42.7.0, app_id /
WM_CLASS `com.anthropic.Claude` / `com.anthropic.Claude.desktop`

## Steps to reproduce

1. Set focus policy to "Focus follows mouse".
2. Open Claude Desktop and one other window, positioned so the other window
partially covers
   Claude Desktop's window (Claude Desktop underneath, partially visible).
3. Move the mouse pointer over the *visible/covered* portion of the Claude
Desktop window,
   without clicking.

## Observed

Claude Desktop's window is immediately raised to the top of the stack —
identical to what
"Click to focus" (or an explicit click) would do — even though no click
occurred.

## Expected

The window should receive keyboard input focus (the shadow correctly
appears/disappears on
hover-in/hover-out, confirming focus tracking itself works) *without* changing
its position in
the stacking order, matching every other window's behavior under the same
policy.

## Things ruled out while investigating (app is closed-source but
Electron-based, so its
main-process JS could be extracted and instrumented)

1. **Not an XWayland artifact.** Reproduces identically whether the app runs
through XWayland
   (its packaged default) or is forced onto native Wayland via
`ELECTRON_OZONE_PLATFORM_HINT=auto`
   (confirmed native via `--ozone-platform=wayland` appearing in its own
child-process argv).

2. **Not triggered by any app-level JS call.** Monkey-patched
  
`BrowserWindow.prototype.{focus,show,showInactive,moveTop,setAlwaysOnTop,blur,restore,setFullScreen}`
   and the app's `browser-window-focus`/`browser-window-blur` events to log
every call with a full
   stack trace. Reproducing the bug (partial cover + hover) produced *only* the
passive native
   `focus`/`blur` events in the log — zero explicit
`.focus()`/`.show()`/`.moveTop()`/
   `.setAlwaysOnTop()`/`.restore()` calls originated from the app's own
JavaScript during the
   raise. Whatever raises the window happens beneath the app's JS layer.

3. **Not caused by lack of window decoration.** The app normally creates its
main window
   frameless/client-side-decorated (Electron `titleBarStyle: 'hidden'`, no
KWin-drawn titlebar).
   Using a KWin Window Rule ("No titlebar and frame" → No, Force) makes KWin
paint a titlebar/
   frame around the window (visibly stacking a second set of
minimize/maximize/close buttons
   alongside the app's own custom ones) — but the auto-raise-on-hover-focus
behavior is
   completely unchanged with or without the forced decoration.

4. **Specific to this one window.** Every other window tested under the
identical focus policy
   (Dolphin, Konsole, System Settings — all native Qt/Wayland; a Chromium
browser window forced
   onto native Wayland the same way) behaves correctly: hover grants focus
without raising.

None of the usual suspects (XWayland vs. native Wayland, app-triggered
raise/focus calls, presence
of window decoration) account for the difference, which points to something in
KWin's own
focus/stacking handling that is specific to this window's `xdg_toplevel`
(possibly a state or
role established once at window-creation time, since forcing decoration
afterward via a Window
Rule doesn't retroactively change it). I was not able to isolate the exact
trigger further from
the client side.

## Additional notes

Happy to provide further diagnostics (KWin debug console output,
`qdbus`/KWin-scripting
introspection of the window's properties, etc.) if useful — just let me know
what to capture.

-- 
You are receiving this mail because:
You are watching all bug changes.