[kwin] [Bug 518616] XWayland does not send FocusOut when focus moves to a native Wayland surface

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

--- Comment #4 from Wehrwolfmann <[email protected]> ---
Correction to my previous comment. I had the cause wrong, and I would rather
say so
before anyone spends time on it.

Last time I wrote that the difference was the input path: a real click
reproduces,
a scripted window activation does not. That is not it. I ran the missing two
cases
and the picture is the opposite of what I claimed. Plasma 6.7.4, KWin
6.7.4-5.1,
Wayland session, wine 11.15, so an X11 client through Xwayland, one 1920x1080
output.

Four runs of the same program, same machine, same session:

  menu opened by timer, window active + focus taken by kdotool  -> closed, 572
ms
  menu opened by timer, window active + focus taken by kdotool  -> closed, 1582
ms
  menu opened by timer, window active + real click on desktop   -> closed, ~2.1
s
                                                                   after the
click
  menu opened from the tray icon + real click on desktop        -> STUCK
  menu opened from the tray icon + focus taken by kdotool       -> STUCK

So how the focus is taken away makes no difference at all. What decides it is
whether the app still holds activation at the moment TrackPopupMenu runs.

The timestamps from the app's own log show why, and they are one millisecond
apart:

  5098  WM_KILLFOCUS      (the panel took activation when I clicked the tray
icon)
  5099  tray sends WM_RBUTTONUP -> TrackPopupMenu starts
  5549  tick, menu open, focus=0
  ...
  13549 tick, menu still open, focus=0, and it stays that way until I kill it

The menu comes up one millisecond after the window has already lost focus.
TrackPopupMenu dismisses itself when its owner loses activation - and there is
nothing left to lose, so the second WM_KILLFOCUS never comes and the loop never
ends.

Worth saying before it gets asked: the test program does what Microsoft's docs
prescribe for tray menus - SetForegroundWindow() right before TrackPopupMenu
and a
PostMessage(WM_NULL) right after. The recipe is there and it does not win the
activation back. Without a compositor in the way, the same binary on Windows
closes
the menu on the desktop click.

This also explains my six "cannot reproduce" answers, and it is not the reason
I gave
last time. Every one of those checks opened the menu on a timer while the
window was
still active. Done that way it closes every single time, whatever you use to
take the
focus. If you verify it that way, you will see it working.

To reproduce: right-click the tray icon of a Wine app that shows a
TrackPopupMenu,
then click anywhere on the desktop. Opening the menu any other way hides the
bug.
I can attach the ~200-line C test program - it registers a real tray icon
through
Shell_NotifyIcon and logs the focus messages plus a tick every 500 ms, so a
hung menu
is plain to see in the log.

Limits, honestly: one machine, one KWin version, one Wine version, and the
click
target was the Plasma desktop. I have not tested clicking another window
instead, and
I have not tested a native Wayland app with a tray menu. Logs, screenshots and
the
program are attached.

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