Bug 463272

Summary: Wrong vertical position of task manager tooltips possibly causing misclicks with media controls
Product: [Plasma] plasmashell Reporter: Patrick Silva <bugseforuns>
Component: Task Manager and Icons-Only Task ManagerAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: ales.astone, asturm, bharadwaj.raju777, dennis.lissov, iodreamify, johnzooi, kde, me, med.medin.2014, mikhail.krutov, nate, notmart, postix, qydwhotmail, timaeos, torokati44
Priority: HI Keywords: wayland
Version: 5.27.4   
Target Milestone: 1.0   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 6.0
Attachments: screen recording
[Wayland] Task Manager thumbnails shown at wrong positions when media controls are displayed
screenshot taken on Plasma 5.27.6

Description Patrick Silva 2022-12-20 16:04:23 UTC
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
Comment 1 Nate Graham 2023-01-05 20:49:25 UTC
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.
Comment 2 Patrick Silva 2023-02-18 21:31:30 UTC
*** Bug 466010 has been marked as a duplicate of this bug. ***
Comment 3 Patrick Silva 2023-03-29 18:28:00 UTC
*** Bug 467927 has been marked as a duplicate of this bug. ***
Comment 4 Patrick Silva 2023-04-02 21:08:46 UTC
*** Bug 468058 has been marked as a duplicate of this bug. ***
Comment 5 Alessandro Astone 2023-04-03 10:11:07 UTC
Note that, as i wrote in my duplicate bug, instead of a gap you might get that the tooltip overlaps the panel
Comment 6 Patrick Silva 2023-04-27 22:29:05 UTC
*** Bug 469076 has been marked as a duplicate of this bug. ***
Comment 7 Denis Lisov 2023-04-28 06:53:25 UTC
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).
Comment 8 Andreas Sturmlechner 2023-05-13 15:12:52 UTC
*** Bug 468352 has been marked as a duplicate of this bug. ***
Comment 9 Bharadwaj Raju 2023-05-15 10:10:06 UTC
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...?
Comment 10 Nate Graham 2023-05-16 19:24:19 UTC
*** Bug 469856 has been marked as a duplicate of this bug. ***
Comment 11 medin 2023-05-20 19:30:49 UTC
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)
Comment 12 Bharadwaj Raju 2023-05-23 10:00:06 UTC
MR with fix: https://invent.kde.org/plasma/kwin/-/merge_requests/4127
Comment 13 Bharadwaj Raju 2023-05-23 13:41:48 UTC
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
Comment 14 Bharadwaj Raju 2023-05-23 13:43:53 UTC
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
Comment 15 Patrick Silva 2023-06-24 13:30:20 UTC
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
Comment 16 Patrick Silva 2023-08-07 13:06:07 UTC
*** Bug 473106 has been marked as a duplicate of this bug. ***
Comment 17 Nate Graham 2023-09-19 18:44:51 UTC
*** Bug 474682 has been marked as a duplicate of this bug. ***
Comment 18 Nate Graham 2023-09-29 15:29:23 UTC
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.