SUMMARY When the panel is at the top of the screen and the kickoff menu in the top-left corner, when clicking the menu icon Claws-mail is opened. STEPS TO REPRODUCE 1. Start Plasma wayland session 2. Place panel at top and the kickoff menu in top-left corner 3. Start claws-mail and minimise to tray 4. Click on the Kickoff menu. OBSERVED RESULT Claws-mail is focused and brought forward. EXPECTED RESULT The kickoff menu to be opened. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20210215 KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.16-1-default ADDITIONAL INFORMATION The keyboard button combination assigned to kickoff still opens the menu. This behaviour is only seen when using a wayland session.
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. ***