Created attachment 154712 [details] screen recording STEPS TO REPRODUCE 1. play a video with an internet browser grouped in the task manager 2. move the mouse pointer vertically 3. hover over another task OBSERVED RESULT Gap between panel and tooltip of the task manager. Please watch the attached screen recording. EXPECTED RESULT no gap SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Graphics Platform: Wayland
Bizarre. 100% reproducible for me, just like in the screen recording: bottom panel, grouped web browser tasks with one playing a video, exact same cursor movement.
*** Bug 466010 has been marked as a duplicate of this bug. ***
*** Bug 467927 has been marked as a duplicate of this bug. ***
*** Bug 468058 has been marked as a duplicate of this bug. ***
Note that, as i wrote in my duplicate bug, instead of a gap you might get that the tooltip overlaps the panel
*** Bug 469076 has been marked as a duplicate of this bug. ***
The old title caused the impression that this is a purely visual inconsistency. The other side of this bug is far more annoying: the tooltip appears over the toolbar button. In this case a click intended to switch to that window changes volume instead, and the user needs to move mouse out and back over the button to finally switch windows (and separately fix the unintended volume change).
*** Bug 468352 has been marked as a duplicate of this bug. ***
Correction (to comment 5 on https://bugs.kde.org/show_bug.cgi?id=468352#c5): The tooltip doesn't in fact open at the same y-position as before. It opens exactly 30 pixels upward/downward of it, in the "correct" direction (i.e. it should actually be more than 30 pixels from it but in the same direction). Here are some logs from adding some prints to dialog.cpp in PF: ------------------- opening small tooltip >>> syncToMainItemSize called >>> setVisible: position is: QPoint(0,840) >>> syncToMainItemSize called >>> repositionIfOffScreen: setting (x, y) = 0 , 840 >>> updateVisibility: position is: QPoint(0,840) >>> syncToMainItemSize called >>> repositionIfOffScreen: setting (x, y) = 0 , 840 >>> updateVisibility: position is: QPoint(0,840) it opened with correct position -------------------- now going to open tall tooltip >>> syncToMainItemSize called >>> setVisible: position is: QPoint(0,810) >>> syncToMainItemSize called >>> repositionIfOffScreen: setting (x, y) = 0 , 810 >>> updateVisibility: position is: QPoint(0,810) >>> repositionIfOffScreen: setting (x, y) = 0 , 776 >>> repositionIfOffScreen: setting (x, y) = 0 , 776 >>> syncToMainItemSize called >>> repositionIfOffScreen: setting (x, y) = 0 , 776 >>> updateVisibility: position is: QPoint(0,776) it opened with wrong position --------------------- now reopening tall >>> syncToMainItemSize called >>> setVisible: position is: QPoint(0,776) >>> syncToMainItemSize called >>> repositionIfOffScreen: setting (x, y) = 0 , 776 >>> updateVisibility: position is: QPoint(0,776) >>> syncToMainItemSize called >>> repositionIfOffScreen: setting (x, y) = 0 , 776 >>> updateVisibility: position is: QPoint(0,776) correct position --------------------- now opening small >>> syncToMainItemSize called >>> setVisible: position is: QPoint(0,776) >>> syncToMainItemSize called >>> repositionIfOffScreen: setting (x, y) = 0 , 806 >>> updateVisibility: position is: QPoint(0,806) >>> repositionIfOffScreen: setting (x, y) = 0 , 840 >>> repositionIfOffScreen: setting (x, y) = 0 , 840 >>> syncToMainItemSize called >>> repositionIfOffScreen: setting (x, y) = 0 , 840 >>> updateVisibility: position is: QPoint(0,840) wrong position ------------------ Turns out (from pixel-measuring screenshots) the wrong position for the tall one is 810, exactly 30 pixels upwards from the correct position of the small tooltip which is 840. Similarly, the wrong position for the small tooltip is 806, exactly 30 pixels downwards from the correct position of the tall tooltip which is 776. I'm not sure what is making this 30 pixel thing happen. Also note how it first says "updateVisibility: position is: <some wrong position>" then soon after we get a similar line with the correct position, but even after that has been printed the tooltip only actually shows up at the first, wrong position. It's like the second time its position change isn't having an effect...?
*** Bug 469856 has been marked as a duplicate of this bug. ***
Created attachment 159148 [details] [Wayland] Task Manager thumbnails shown at wrong positions when media controls are displayed I'm also suffering from this bug on Wayland, the thumbnails are either shown above the panel with a vertical gap or it overlaps the panel, this happens when an app is playing a music or a video and it also affects others apps' thumbnails (without media controls)
MR with fix: https://invent.kde.org/plasma/kwin/-/merge_requests/4127
Git commit 539b6bb6ac3a58049b96106de55004806c639821 by Bharadwaj Raju. Committed on 23/05/2023 at 13:41. Pushed by bharadwaj-raju into branch 'master'. XdgPopupWindow: Allow position to be set by Plasma This lets Plasma itself control the position of popup windows such as Plasma tooltips. transientPlacement() now returns the position set by Plasma if available. M +4 -1 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/commit/539b6bb6ac3a58049b96106de55004806c639821
Git commit 4d4769b8c5b3ddd5b3bfae6dc7fb4cf7057127a6 by Bharadwaj Raju. Committed on 23/05/2023 at 13:43. Pushed by bharadwaj-raju into branch 'Plasma/5.27'. XdgPopupWindow: Allow position to be set by Plasma This lets Plasma itself control the position of popup windows such as Plasma tooltips. transientPlacement() now returns the position set by Plasma if available. (cherry picked from commit 539b6bb6ac3a58049b96106de55004806c639821) M +4 -1 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/commit/4d4769b8c5b3ddd5b3bfae6dc7fb4cf7057127a6
Created attachment 159880 [details] screenshot taken on Plasma 5.27.6 As we can see in the screenshot attached to this comment, the bug persists on Plasma 5.27.6. Operating System: Arch Linux KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 Graphics Platform: Wayland
*** Bug 473106 has been marked as a duplicate of this bug. ***
*** Bug 474682 has been marked as a duplicate of this bug. ***
Now on Plasma 6 Wayland, after the big dialog refactor, the way I was able to reproduce it before isn't reproducing it anymore! The dialog changes are logically related, so I think we can say that they've fixed the issue.