| Summary: | Context menu popup misplaced in process tables with multi-screen setup when window is on right-most screen | ||
|---|---|---|---|
| Product: | [Applications] plasma-systemmonitor | Reporter: | Damglador <vse.stopchanskyi> |
| Component: | general | Assignee: | KSysGuard Developers <ksysguard-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ahiemstra, bugseforuns, equeim, evgeniyharchenko.dev, im.tech.tac, john.kizer, kde, kdedev, madness742, nate, nicolas.fella, plasma-bugs-null, postix, quarro, sephiroth_pk, slartibart70, steel_heart |
| Priority: | NOR | Keywords: | multiscreen, regression |
| Version First Reported In: | 6.3.4 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=510503 | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-systemmonitor/-/commit/ae7627557261d7cb6f930fd07f4590ea4f392c50 | Version Fixed/Implemented In: | 6.5.3 |
| Sentry Crash Report: | |||
| Attachments: |
Right click menu is far away from the click position
misplaced context menu after right-click on a column in "Overview" page on 2nd screen overview settings-laptop settings-4k coredump1 coredump2 In widget edit menu |
||
Hi - for what it's worth, I can't reproduce on Fedora KDE 41 - which still has Qt 6.8.2, possibly related? Cannot reproduce with git master plasma-systemmonitor but Qt 6.8.2. Could be a Qt 6.9 regression. I see this bug in Fedora 42 (Qt 6.9.0), but not in Plasma built from git-master (Qt 6.8.2) There's a duplicate from someone who also has Qt 6.9.0 *** Bug 503226 has been marked as a duplicate of this bug. *** Created attachment 180654 [details]
misplaced context menu after right-click on a column in "Overview" page
Same bug after right-click on a column in "Overview" page.
Operating System: Arch Linux
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.13.0
Qt Version: 6.9.0
Graphics Platform: Wayland
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-systemmonitor/-/merge_requests/356 *** Bug 504063 has been marked as a duplicate of this bug. *** Git commit df7f22ab23499c6a8851b3b3262d4294925a401f by Arjen Hiemstra. Committed on 12/05/2025 at 10:08. Pushed by ahiemstra into branch 'master'. faces/*table: Fix positioning of context menus with Qt >= 6.9 Not entirely sure how behaviour changed here but popups ended up incorrectly positioned with newer Qt. M +4 -2 src/faces/applicationstable/contents/ui/FullRepresentation.qml M +4 -2 src/faces/processtable/contents/ui/FullRepresentation.qml https://invent.kde.org/plasma/plasma-systemmonitor/-/commit/df7f22ab23499c6a8851b3b3262d4294925a401f *** Bug 504096 has been marked as a duplicate of this bug. *** *** Bug 504140 has been marked as a duplicate of this bug. *** Hi, i'm testing with plasma-systemmonitor-6.3.80~16.git7f7856f-1.fc42.x86_64 and the problem is still not resolved (although the 'fix' is in the commit-history?)` It's fixed for me with that commit, also on Fedora 42. I would suspect a packaging issue with that package, unless you're still using Qt 6.8.x for some reason, in which case that's why. sorry to say, but no - not fixed... completely :-) It works on a single-screen or on a multi-screen-setup if you are on the main-screen: Here for example, if opening system-monitor window on the laptop-screen (with additional +4K monitor) If you call system-monitor on the 4K screen, then it's still broken (see attachments) Operating System: Fedora Linux 42 KDE Plasma Version: 6.3.80 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.0 Kernel Version: 6.14.6-300.fc42.x86_64 (64-bit) Graphics Platform: Wayland Created attachment 181343 [details]
on 2nd screen
And, if you open the window on the laptop screen (Meta-ESC) it works. Don't close the window, move it to the 4K screen: and it still works (context-menu is at mouse-pointer position) But, if you initially start on 4K screen with (Meta-ESC), the context-menu still opens on the far right side Could you please attach a screenshot of your screen arrangement? I cannot immediately reproduce with two screens. Created attachment 181519 [details]
overview
Created attachment 181520 [details]
settings-laptop
Created attachment 181521 [details]
settings-4k
I have almost exactly the same screens and screen arrangement (the difference being a 23" 1440p external monitor rather than 27" 4K, but otherwise the same) and I can't reproduce the issue with the fix on my system. how can i help any further? even with latest updates (git), the problem is still there Unclear. You're the only one who still seems to be able to reproduce the issue with the fix applied on with a multi-monitor setup, and we haven't found out what's different between your system and everyone else's well, maybe one thing: the 4K monitor is attached to a thunderbolt-4 box using usb-c ? does this help? Mine is plugged in via USB-C as well, though only to a USB-C+DP+PD port in the laptop, not a Thunderbolt port. kscreen-doctor -o
Output: 1 eDP-1 e76f9ff2-7305-4bb4-bd07-e63d4dc45b41
enabled
connected
priority 1
Panel
replication source:0
Modes: 1:2880x1800@60*! 2:1920x1200@60 3:1920x1080@60 4:1600x1200@60 5:1680x1050@60 6:1280x1024@60 7:1440x900@60 8:1280x800@60 9:1280x720@60 10:1024x768@60 11:800x600@60 12:640x480@60 13:1600x1200@60 14:1280x1024@60 15:1024x768@60 16:2560x1600@60 17:1920x1200@60 18:1280x800@60 19:2880x1620@60 20:2560x1440@60 21:1920x1080@60 22:1600x900@60 23:1368x768@60 24:1280x720@60
Geometry: 0,0 2304x1440
Scale: 1.25
Rotation: 1
Overscan: 0
Vrr: incapable
RgbRange: unknown
HDR: disabled
Wide Color Gamut: disabled
ICC profile: none
Color profile source: sRGB
Color power preference: prefer efficiency and performance
Brightness control: supported, set to 20% and dimming to 100%
Color resolution: automatic (10), range: [8; 16] bits per color
Allow EDR: always
Output: 2 DP-5 325a5680-6400-4830-b748-a193fd3a6cc4
enabled
connected
priority 2
DisplayPort
replication source:0
Modes: 25:3840x2160@60*! 26:3840x2160@30 27:1920x1200@60 28:1920x1080@60 29:1920x1080@60 30:1920x1080@60 31:1920x1080@50 32:1600x1200@60 33:1680x1050@60 34:1600x900@60 35:1280x1024@60 36:1440x900@60 37:1280x800@60 38:1280x720@60 39:1280x720@60 40:1280x720@60 41:1280x720@50 42:1024x768@60 43:800x600@60 44:720x576@50 45:720x576@50 46:720x480@60 47:720x480@60 48:720x480@60 49:720x480@60 50:640x480@60 51:640x480@60 52:640x480@60 53:720x400@70 54:1600x1200@60 55:1280x1024@60 56:1024x768@60 57:2560x1600@60 58:3200x1800@60 59:2880x1620@60 60:2560x1440@60 61:1920x1080@60 62:1600x900@60 63:1368x768@60 64:1280x720@60
Geometry: 2304,0 3840x2160
Scale: 1
Rotation: 1
Overscan: 0
Vrr: incapable
RgbRange: unknown
HDR: incapable
Wide Color Gamut: incapable
ICC profile: none
Color profile source: sRGB
Color power preference: prefer efficiency and performance
Brightness control: unsupported
Color resolution: automatic (10), range: [8; 16] bits per color
Allow EDR: unsupported
all other context-menus are where they should be... (krusader, dolphin, others) One more thing regarding system-monitor: It's really only the right-click on the applications (or processes) list items. If i click on the columns, the contextmenu is exactly at the mouse pointer position. Even in applications, with details (sidebar on the right) enabled, right-clicking in the cpu/memory/network graphs shows the context menu spot on at the mouse-pointer. Maybe one additional hint...as unlikely as it sounds: i'm using a left-handed mouse, so the buttons are swapped Does it stop happening if you un-swap the buttons? no, does not change anything if mouse is right/left handed but, i got a coredump of systemsettings (before switching mouse handedness) ... preparing logs for attachment Created attachment 181544 [details]
coredump1
Created attachment 181545 [details]
coredump2
the coredumps just happen after clicking (more than usual) in the various panels of systemmonitor. No changes to the pages, just clicking on items, columns, switching pages and so forth sorry... i meant systemmonitor (not systemsettings as in comment #28) Created attachment 181667 [details]
In widget edit menu
I encountered something similar in the widget edit mode when I hove over "Delete widget" and such buttons. But instead of being shifted to the left, it's shifted to the right
The remaining issue that only affects the multi-screen use case has been fixed in Qt with https://codereview.qt-project.org/c/qt/qtbase/+/648321, thanks to Vlad Zahorodnii! If that gets backported, it'll show up in a Qt 6.9.x release eventually too. Unclear right now whether this will happen. *** Bug 505817 has been marked as a duplicate of this bug. *** *** Bug 506623 has been marked as a duplicate of this bug. *** (In reply to Nate Graham from comment #36) > *** Bug 506623 has been marked as a duplicate of this bug. *** (In reply to Nate Graham from comment #34) > The remaining issue that only affects the multi-screen use case has been > fixed in Qt with https://codereview.qt-project.org/c/qt/qtbase/+/648321, > thanks to Vlad Zahorodnii! > > If that gets backported, it'll show up in a Qt 6.9.x release eventually too. > Unclear right now whether this will happen. I still have this issue with Plasma 6.4.5 and Qt 6.10.0 I can reproduce it again too in Plasma 6.5.0. Looks like that fix didn't fully fix it, or it regressed somewhere. The issue is 100% reproducible for me when System Monitor's window is on the right-most screen. Primary vs non-primary doesn't seem to make a difference. It is always reproducible on all screens when using a vertical arrangement in Plasma 6.5.0. Lowering priority as it takes a specific hardware configuration to experience, and it's a fairly minor issue when it does happen. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-systemmonitor/-/merge_requests/396 Git commit aeacabc8ab8194d3a719576b51fcd7698013289e by Nate Graham, on behalf of Oliver Schramm. Committed on 12/11/2025 at 15:59. Pushed by ngraham into branch 'master'. table: use scenePosition for context menu positioning This is what the header context menu uses, which is the right approach for avoiding the positioning bug in question. FIXED-IN: 6.5.3 M +1 -1 src/table/BaseTableView.qml https://invent.kde.org/plasma/plasma-systemmonitor/-/commit/aeacabc8ab8194d3a719576b51fcd7698013289e Git commit ae7627557261d7cb6f930fd07f4590ea4f392c50 by Nate Graham. Committed on 12/11/2025 at 15:59. Pushed by ngraham into branch 'Plasma/6.5'. table: use scenePosition for context menu positioning This is what the header context menu uses, which is the right approach for avoiding the positioning bug in question. FIXED-IN: 6.5.3 (cherry picked from commit aeacabc8ab8194d3a719576b51fcd7698013289e) 223b8d5e table: use scenePosition for context menu Co-authored-by: Oliver Schramm <oliver@oliver-schramm.eu> M +1 -1 src/table/BaseTableView.qml https://invent.kde.org/plasma/plasma-systemmonitor/-/commit/ae7627557261d7cb6f930fd07f4590ea4f392c50 |
Created attachment 180203 [details] Right click menu is far away from the click position SUMMARY I'm not sure if this is a bug of system monitor or some library, because downgrading it to 6.3.1, in which it didn't have such an issue, didn't fix anything. The right click menu in process tables is shifted far down-right, be it right-click on a process or table a header. See attachment STEPS TO REPRODUCE 1. Open system monitor 2. Right-click on a process OBSERVED RESULT The menu is far down-right EXPECTED RESULT The menu should be on the cursor SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.9.0 Kernel Version: 6.14.2-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600H with Radeon Graphics Memory: 13.5 GiB of RAM Graphics Processor 1: AMD Radeon Graphics Graphics Processor 2: NVIDIA GeForce RTX 3060 Laptop GPU ADDITIONAL INFORMATION