When hovering over the apps in the taskbar, usually a windows preview opens. That so far works without any problems. But if I move my mouse to the window, sometimes it disappears. The reason for that is the gap between the window preview and the taskbar. If the mouse is placed there (while moving it), the preview disappears. I often have this problem:
I wouldn't call this a Bug. This is the normal Window Behavior. When You are on the Icon, you get the Preview. And then You can go on the Preview an click on it.
No, that is the problem: Often times I can't click on it, because it disappears while I try to move my mouse to it to click on it.
Here you can also see a screencast, though the pointer unfortunately is not visible due to another bug (#5216@gitlab.gnome.org) in the screencast software:
A diagonal move of the mouse, which happens if one has many apps opened, is more likely to trigger this bug.
Hmm ... Okay. I opened several Windows but can't reproduce it. But that doesn't have to mean anything. Did You tried to change between Xorg and Wayland?
Beause of the Mouse Cursor: You have to activate it on the Screenshot Tool what You see. there should be in the bottom right Corner a Mouse Cursor wher You have to click on.
Hmm, I am afraid of Wayland because I don't want to break anything, since I have great performance so far with Xorg (when I tried KDE 6, it was not good, I believe they already moved to Wayland).
Mouse Cursor: On screenshots it is visible, but not on screencasts. Seems to be a very old bug of GNOME.
When You have a Nvidia Graphics it would be better to stay on Xorg. Plasma 6 is running by default Wayland as far as I know but You can change to Xorg.
I never had this problem, no one should. To make it disappear you must be moving the cursor to the preview really slowly, enough slow to remove the focus to the icon and so preventing the preview from being displayed. Actually if you stay in the gap the preview closes but this is intended, the preview “hitbox” is the visible container itself and doesn't extends even to that gap. The feature is meant to show the preview on hover and simply moving the cursor fast from the icon to the preview works, just try pointing an icon and do a faster short movement upward. Or you mean that despite you move the cursor fast from the icon to the preview is failing to show the software? In this case, this would be an issue.
I am a heavy user with the whole bottom filled up with previews. You can either move the cursor up and then right and then move it to the desired preview, or, how I often do it (after decades of using Windows) I move the cursor right, then move it diagonally to the desired preview. If the mouse then stays on the taskbar for too many milliseconds, the preview disappears.
Windows may have resolved that by following way: The user is moving its mouse after opening the preview. As long he does that, we need to wait what he wants to do. Start the timeout only if the mouse stops.
Interestingly it seems there is another bug, but I am not sure yet. It seems that the preview even disappears if I have my mouse on the preview. I noticed that now several times while working. I will later try to make a screencast of it and well, maybe I have time one day to look into the source code, but there is definitely some unnatural behaviour going on with that.
I did a quick test on this using LiveCD and was able to easily replicate it.
As different users will have different motions and speeds in using their mouse, this is a bug that should be addressed and corrected in order to make the desktop the most usable to the most number of users.
The cause is a slight gap in the area between the panel and the preview that when the cursor is placed in that gap, this removes the call for the preview causing it to close.
I needed to get back onto my daily driver and handle a different work call so I did not have time to test if simply making an adjustment to a custom .css file to the margins would close that gap but if so; a user can adjust this on their own user account to patch things up.
Thanks for testing and pointing out how important it is to address such issues. I were looking in /usr/share/gnome-shell/extensions/zorin-taskbar@zorinos.com but I only find stylesheet.css which doesn't contain much.
Do you know if there is another .css file for the taskbar/window preview?
Good evening again!
I have now done some further analysis. So, we have two bugs here:
Bug 1: Gap Issue
The already shown gap issue. It can be temporarily fixed by setting MARGIN_SIZE to 0 in /usr/share/gnome-shell/extensions/zorin-taskbar@zorinos.com/windowPreview.js. Should not bother much, but clearly violates the theme, so in the long run we need to think about how we can address hat.
I reported it here, but the timeout change didn't do the trick.
Bug 2: Immediate close after opening
Another bug I mentioned today: Sometimes the preview disappears even if the mouse is straight on the preview. Here you can see it on video. I did some analysis of the code (windowPreview.js) and I suspect that the issue comes from St.Widget which might be something from the GNOME Shell.
The reason for that is that when _onHoverChanged() is fired, the taskbar will check for the hover state and only closes if it returns false, which – ererroneously – seems to be the case. It seems that I could temporarily fix it by syncing the hover state before the check takes place, I described in this report on the Dash to Panel GitHub page:
_onHoverChanged() {
this._endOpenCloseTimeouts();
if (this.currentAppIcon) {
// This call seems to resolve it
this.menu.sync_hover();
if (!this.menu.hover) {
this._addCloseTimeout();
this._endPeek();
}
}
}
(In order to reload the taskbar, just use [Alt]+[F2] and then enter r)