Bug 433079

1. Does this still happen if you click on the bottom-right corner of the kickoff icon, not the top-left corner of it?

2. Do you have compositing turned off?

If both are true, this is probably an example of Bug 432744.

Ad 1: Yes, this happens whenever and where-ever I click on the kickoff icon. This only happens if the panel is placed at top or left, where kickoff is residing in the top-left corner. When placed on the right or bottom there is no issue.

When I close claws-mail it starts working again. The action might switch to a different gtk program. Though the behaviour is the same, the menu is not opening.

This behaviour is only seen when using Wayland. 

Ad 2: I have compositing enabled, with plasma 5.21 I don't see how to turn it off. In the issue you relate to there is no black square for me on the top-left corner. It all looks clean as expected.

Thanks. Some more questions for you:

3. If you move your panel elsewhere so that the Kickoff icon is no longer in the top-left corner, does claws-mail still open if you click in that spot in the top-left corner?

4. Does the problem go away if you run `killall xembedsniproxy` in a terminal window?

Ad 3: The behaviour is tied to the top-left corner. When I click there it opens claws. The click action becomes available roughly when you see the expose illumination come up.

Ad 4: That stopped the behaviour but also made claws hide, so that I can't acces it. 

Thus it does seem related to your issue.

I had a feeling. It's the same issue--or at least the same underlying root cause.

*** This bug has been marked as a duplicate of bug 432744 ***

*** Bug 433396 has been marked as a duplicate of this bug. ***

Just to be sure - can you test on X11, to confirm that it only affects Wayland?

*** Bug 438690 has been marked as a duplicate of this bug. ***

(In reply to Konrad Materka from comment #7)
> Just to be sure - can you test on X11, to confirm that it only affects
> Wayland?

I have the same problem but with MegaSync instead of Claws-mail and it happened only after I switched to Wayland (because devs keep saying plasma is now wayland-ready so I tried)! So yeah, doesn't happen in X11 :)

*** Bug 444009 has been marked as a duplicate of this bug. ***

*** Bug 418370 has been marked as a duplicate of this bug. ***

I have the same issue and can confirm that it only happens in wayland and also only for autostart applications.
If i close these apps and reopen them, the click hit rect seems to be in the right spot

It only happens under Wayland. Anydesk has the same issue. I have stopped using / trying Wayland because of this issue.

Reproduced with hexchat:

killall -9 xembedsniproxy ; QT_LOGGING_RULES=kde.xembedsniproxy.debug=true xembedsniproxy
Qt: Session management error: Could not open network socket
kde.xembedsniproxy: starting
kde.xembedsniproxy: Manager selection claimed
kde.xembedsniproxy: trying to dock window  16780239
kde.xembedsniproxy: adding damage watch for  16780239
kde.xembedsniproxy: Resizing window 16780239 "hexchat" from w*h QSize(200, 200)
Container window visible, stack below
kde.xembedsniproxy: Skip transparent xembed icon for 16780239 "hexchat"
kde.xembedsniproxy: No xembed icon for 16780239 "hexchat

Log: "Container window visible, stack below" is printed when we detect that "XEmbed" window is visible. Here is the check:
https://invent.kde.org/plasma/plasma-workspace/-/blob/Plasma/5.23/xembed-sni-proxy/fdoselectionmanager.cpp#L149
It is fully transparent so that you can't see it, but it is there - initially in right left corner. It should be stacked behind desktop so that it does not obscure anything. It may happen, even on X11, that it will pop up on top (for example during/after KWin restart) that's why we have this check.

Seems that stacking X11 windows doesn't work on Wayland. Probably not only this - in Bug 448050 clicks does not work, I'm pretty sure that "XEmbed" window is not moved - it should move to receive click correctly.

Unfortunately right now I cannot test it (NVIDIA...) but this is above my skills anyway. It might be that XWayland is not handling STACK and WINDOW_X/_Y properties, it is also possible that KWin forbids/ignores those - don't know.

xembedsniproxy was a dirty hack on X11, I'm not surprised that it doesn't work on Wayland - I'm surprised it partially works! :)

Good test would be to check if xembedsniproxy works on Gnome on Wayland.

PS. This log should use qCDebug, ops...

*** Bug 449841 has been marked as a duplicate of this bug. ***

I was am also having this issue with Megasync on Wayland.

While not a permanent solution, I was able to resolve it by using a window rule to match against the "megasync" window class and then force disable compositing.

*** Bug 453441 has been marked as a duplicate of this bug. ***

*** Bug 453581 has been marked as a duplicate of this bug. ***

*** Bug 454623 has been marked as a duplicate of this bug. ***

*** Bug 457424 has been marked as a duplicate of this bug. ***

No reports from Plasma 5.26 yet, and I can't reproduce the issue myself anymore.

Is anyone who was previously experiencing this issue still able to reproduce it in Plasma 5.26 or later?

I am still experiencing this issue on my machine

Operating System: Arch Linux
KDE Plasma Version: 5.26.3
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.7
Kernel Version: 6.0.8-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i7-1185G7 @ 3.00GHz
Memory: 31,1 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics
Manufacturer: LENOVO
Product Name: 20XWCTO1WW
System Version: ThinkPad X1 Carbon Gen 9

Ok, thanks a lot!

Created attachment 153789 [details]
expose highlight

It is still there in 5.26.3. Once the expose illumination comes you can't access the kicker menu and only the application in that corner will open. That application is the same consistently, no matter how many GTK applications you have open.

The Bug is still there. Happens with wire and beyond all reason. Is there some idea how to fix this

Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-10-amd64 (64-bit)
Graphics Platform: Wayland

I am able to reproduce this issue in Plasma 5.27.8.

*** Bug 475613 has been marked as a duplicate of this bug. ***

This issue has been blocking me to make the switch to Wayland. I have however made the jump to Wayland and this issue is not present for me, but now the app indicator is not showing claws-mail in the system-tray. I don't know whether those are related. Expose works correctly, I can access the kicker menu, but I don't see my mail indicator.

Operating System: openSUSE Tumbleweed 20231013
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.11
Kernel Version: 6.5.6-1-default (64-bit)
Graphics Platform: Wayland

*** Bug 476782 has been marked as a duplicate of this bug. ***

Operating System: Arch 
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6
Kernel Version: 6.6.19
Session: wayland

Since this has been 100% reproducible for me with Discord on Plasma 6  I finally decided to look into this. 

I was mucking around in sniproxy.cpp and it seems like this is actually needs attention both in SNIproxy and systemtray/statusnotifier.

There is no mechanism to for SNIproxy to know where it "should" be until it receives an event from StatusNotifierItemJob::performJob(), so it can't occupy the correct position and it just exists at (0,0) until a click/scroll action goes through and tells it where it needs to be.

The constructor in sniproxy.cpp just dumps it at (0,0) since it needs to be "somewhere"

148 >    // move window we're embedding
149 >    const uint32_t windowMoveConfigVals[2] = {0, 0};
150 > 
151 >    xcb_configure_window(c, wid, XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y, windowMoveConfigVals);

and it doesn't get moved until SNIProxy::sendClick() is triggered by the Activate, SecondaryActivate, ContextMenu, or Scroll functions.

522 >    // move our window so the mouse is within its geometry
523 >    uint32_t configVals[2] = {0, 0};
524 >    const QPoint clickPoint = calculateClickPoint();
525 >    if (mouseButton >= XCB_BUTTON_INDEX_4) {
526 >        // scroll event, take pointer position
527 >        auto cookie = xcb_query_pointer(c, m_windowId);
528 >        UniqueCPointer<xcb_query_pointer_reply_t> pointer(xcb_query_pointer_reply(c, cookie, nullptr));
529 >        configVals[0] = pointer->root_x;
530 >        configVals[1] = pointer->root_y;
531 >    } else {
532 >        configVals[0] = static_cast<uint32_t>(x - clickPoint.x());
533 >        configVals[1] = static_cast<uint32_t>(y - clickPoint.y());
534 >    }
535 >    xcb_configure_window(c, m_containerWid, XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y, configVals);

Once this code block in executes the bug fixes itself.

So systemtray/statusnotifier needs to be able to query it's position when initialized and needs to pass that to SNIProxy to properly initialize it's own position.

Promoting this to be a 15-minute bug since it's Wayland-only and the Wayland-session is the default in Plasma 6 now.

*** Bug 470773 has been marked as a duplicate of this bug. ***

*** Bug 484879 has been marked as a duplicate of this bug. ***

*** Bug 485474 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4324

*** Bug 459534 has been marked as a duplicate of this bug. ***

*** Bug 485971 has been marked as a duplicate of this bug. ***

*** Bug 487166 has been marked as a duplicate of this bug. ***

Git commit 50bbe56bb08f9b265ad56510e2adc37db66f4d2d by Vlad Zahorodnii, on behalf of David Edmundson.
Committed on 23/05/2024 at 11:20.
Pushed by vladz into branch 'master'.

xembedsniproxy: Set input region when hidden to avoid grabbing clicks

xembedsniproxy is a hidden window. It is used for grabbing content and
replaying events.
It tried to hide itself by adjusting the stacking order.

This is insufficient on wayland where we might be the lowest X window,
but that can still be above the desktop. Instead set an empty shape
when we should be hidden.


### Test plan

Had a floating compact panel (this is important as it means the system tray icon moves about when I open new windows)

Ran hexchat and clicked on the icon and and other icons.

xembedsniproxy was compiled with "VISUAL_DEBUG" flag enabled so I could see where to click, and now (with XWayland >= 2.41) events are never intercepted from the panel.

<!--
If this merge request introduces a visual change, please add before-and-after screenshots in the following format:

| Before | After |
| ------ | ----- |
| [drag "before" screenshot here] | [drag "after" screenshot here] |
-->

### Bugs fixed
<!--
If the changes in this merge request fix any Bugzilla tickets, add the following keyword for each one:
-->

M  +32   -16   xembed-sni-proxy/sniproxy.cpp
M  +1    -1    xembed-sni-proxy/sniproxy.h

https://invent.kde.org/plasma/plasma-workspace/-/commit/50bbe56bb08f9b265ad56510e2adc37db66f4d2d

*** Bug 454847 has been marked as a duplicate of this bug. ***