Bug 444142

Summary: Setting window tooltips as click action in task manager shifts previewed app as mouse moves
Product: [Plasma] plasmashell Reporter: David <david.cortes.rivera>
Component: Task Manager and Icons-Only Task ManagerAssignee: Eike Hein <hein>
Status: RESOLVED FIXED    
Severity: minor CC: bharadwaj.raju777, nate, plasma-bugs, qydwhotmail
Priority: NOR    
Version: 5.23.1   
Target Milestone: 1.0   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 5.24
Sentry Crash Report:

Description David 2021-10-20 20:10:20 UTC
SUMMARY
If I set the icons-only task manager to show window previews when clicking a grouped task, and then go and click one and move the mouse pointer to a different icon, the window previews will be shown for the app that the mouse is pointing at, not the app that was clicked.

STEPS TO REPRODUCE
1. Set the icons-only task manager, right-click, select "configure" -> "Behavior"- > Clicking grouped task -> Show tooltip window thumbnails.
2. Open several windows of some app so that it would become grouped, and one or more windows of a different app whose icon would be right next to the icon of the first app.
3. Left-click the first app's icon in the task manager.
4. Move the mouse pointer to the second app.

OBSERVED RESULT
Shows window previews of the second app.

EXPECTED RESULT
Should show window previews of the grouped app that was clicked.

SOFTWARE/OS VERSIONS
Operating System: Debian GNU/Linux
KDE Plasma Version: 5.23.0
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.0-3-amd64 (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 2700 Eight-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: AMD VEGA10

ADDITIONAL INFORMATION
Comment 1 Nate Graham 2021-10-21 13:09:05 UTC
Can reproduce.
Comment 2 Bharadwaj Raju 2021-10-21 13:13:59 UTC
Is the real problem actually that when you open a tooltip and try to move your mouse into it, you accidentally cross other apps and their tooltips activate? If so, that is bug 358930.
Comment 3 Nate Graham 2021-10-21 13:42:05 UTC
No, it's actually not that. The problem is that when you click on a grouped app with these settings, it pre-selects the first thumbnail in the tooltip, which automatically causes its window to be highlighted. When you move the cursor over to another app, the tooltip changes to show that app, with the first thumbnail (which is now something else) still pre-selected, so the highlighted app changes.

Probably when you click on a grouped app to show tooltips, we shouldn't automatically select any of the thumbnails in it.
Comment 4 Bharadwaj Raju 2021-10-21 13:46:59 UTC
(In reply to Nate Graham from comment #3)
> No, it's actually not that. The problem is that when you click on a grouped
> app with these settings, it pre-selects the first thumbnail in the tooltip,
> which automatically causes its window to be highlighted. When you move the
> cursor over to another app, the tooltip changes to show that app, with the
> first thumbnail (which is now something else) still pre-selected, so the
> highlighted app changes.
> 
> Probably when you click on a grouped app to show tooltips, we shouldn't
> automatically select any of the thumbnails in it.

Having a thumbnail pre-selected only happens if you're 1) using Wayland and 2) have previously clicked on a thumbnail to activate it. This is a bug. See my MR https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/494.

Since OP is using X11, either that bug isn't Wayland-specific as I thought, or they're actually describing a symptom of bug 358930.
Comment 5 David 2021-10-21 14:18:09 UTC
It's not the same as 358930 since it happens with only one row, and as far as I can tell there is no pre-selected window within the thumbnails when I first click them. And yes, this is X11.
Comment 6 Bharadwaj Raju 2021-10-21 14:20:09 UTC
Bug 358930 is not only for multiple rows, it happens with single rows as well
Comment 7 Fushan Wen 2021-10-21 14:27:49 UTC
It seems to fix the bug, a new logic is needed like:

if isToolTipOpenByClick; then
  ignore containsMouse events until timeout
Comment 8 Bharadwaj Raju 2021-10-21 14:32:04 UTC
(In reply to qydwhotmail from comment #7)
> It seems to fix the bug, a new logic is needed like:
> 
> if isToolTipOpenByClick; then
>   ignore containsMouse events until timeout

That would be a general solution to bug 358930 as well. Except, adding timeouts like that will make the UI less responsive. We can fix the problem without relying on timeouts. The ideal solution is a triangle mouse filter, see https://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown. I'm working on adding a triangle mouse filter to the task manager, which will fix both this and the other bug.
Comment 9 David 2021-10-21 14:36:43 UTC
I guess it is the same underlying cause as in 358930, but this happens with a left-click so I don't think the solution to that bug would do, since that's just a 100ms timeout for re-generating on-hover previews, whereas for a left-click I think most people would expect the previews to stay there, since they are supposed to be generated on click and not on hover.

I think a more logical action would be for them to disappear after a longer timeout without showing the previews of a different app, like in MS windows and in earlier versions of latte.
Comment 10 Bharadwaj Raju 2021-10-21 14:38:49 UTC
Just to clarify, you're encountering this bug when you try to move your mouse in a diagonal to a window in the opened tooltip, and you cross over another app, right?
Comment 11 David 2021-10-21 14:43:48 UTC
(In reply to Bharadwaj Raju from comment #10)
> Just to clarify, you're encountering this bug when you try to move your
> mouse in a diagonal to a window in the opened tooltip, and you cross over
> another app, right?

It does happens like that and most of the times that is what makes it so annoying, but I also encounter this bug while moving the mouse horizontally, deviating from a straight diagonal (e.g. the previews span 5 icons, I move horizontally and then upwards, now the previews are from a different app).
Comment 12 Fushan Wen 2021-10-21 14:44:46 UTC
The timeout should be "the tooltip will disappear after 4s without any action". So I think it's easier to fix and different from 358930.
Comment 13 Bug Janitor Service 2021-10-22 10:44:54 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/628
Comment 14 Nate Graham 2021-10-28 17:41:49 UTC
Git commit f8798ba69aa0f4e29c2fde035a87932379678040 by Nate Graham, on behalf of Bharadwaj Raju.
Committed on 28/10/2021 at 17:41.
Pushed by ngraham into branch 'master'.

Introduce dismissOnHoverLeave property and toolTipVisibleChanged signal

Introduces new signal `toolTipVisibleChanged(bool toolTipVisible)`, so users can be
signalled when the tooltip is shown or hidden.

This is needed for implementing a fix to https://bugs.kde.org/show_bug.cgi?id=444142,
so that tooltips opened with a click are not dismissable by hovering over another Task.

M  +2    -0    src/declarativeimports/core/tooltip.cpp
M  +6    -0    src/declarativeimports/core/tooltip.h

https://invent.kde.org/frameworks/plasma-framework/commit/f8798ba69aa0f4e29c2fde035a87932379678040
Comment 15 Nate Graham 2021-10-28 17:45:47 UTC
Git commit 62a9ff23e95ce84b39bb7e9854f8e1b181a20e07 by Nate Graham, on behalf of Bharadwaj Raju.
Committed on 28/10/2021 at 17:45.
Pushed by ngraham into branch 'master'.

applets/taskmanager: Don't open other tooltips by hover if current one was opened by click
Related: bug 430438
FIXED-IN: 5.24

M  +16   -1    applets/taskmanager/package/contents/ui/Task.qml
M  +1    -1    applets/taskmanager/package/contents/ui/ToolTipWindowMouseArea.qml
M  +7    -1    applets/taskmanager/package/contents/ui/code/tools.js
M  +2    -0    applets/taskmanager/package/contents/ui/main.qml

https://invent.kde.org/plasma/plasma-desktop/commit/62a9ff23e95ce84b39bb7e9854f8e1b181a20e07