You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a bug which leads to the previews being closed even if the user has opened the previews and the mouse is still within the previews area. Unfortunately there is another bug in GNOME which leads to the pointer being not visible when recording, so I was required to record it using a smartphone. I am using two monitors, one with 60 Hz and one with 165 Hz, both with a resolution of 2560x1440. Which one is used doesn't make a difference for me.
I suspect that the bug comes from St.Widget, since this.menu.hover ererroneously returns false, even if the mouse is on the preview. I don't know why St.Widget has problems with setting the correct hover state, but as a workaround it seems that a sync_hover() on this.menu before checking the current hover state fixes it:
_onHoverChanged() {
this._endOpenCloseTimeouts();
if (this.currentAppIcon) {
this.menu.sync_hover();
if (!this.menu.hover) {
this._addCloseTimeout();
this._endPeek();
}
}
}
Note that currently it is not possible to correctly track the hover
state when another actor has a pointer grab. You can use
St.Widget.sync_hover to update the property manually in this
case.
Maybe I got luck and this is the right way to fix it, but as I don't have much knowledge about GNOME at all, I refrained from creating a pull-request. Would be great though if someone could confirm and fix this issue :)
Linux distribution and version
Zorin OS 17
GNOME Shell version
GNOME Shell 43.9
The text was updated successfully, but these errors were encountered:
There is a bug which leads to the previews being closed even if the user has opened the previews and the mouse is still within the previews area. Unfortunately there is another bug in GNOME which leads to the pointer being not visible when recording, so I was required to record it using a smartphone. I am using two monitors, one with 60 Hz and one with 165 Hz, both with a resolution of 2560x1440. Which one is used doesn't make a difference for me.
Screenshots / Video captures
https://www.youtube.com/watch?v=gPpXwq75fcc
Analysis
I did some analysis. First look at this code in
windowPreview.js
:I suspect that the bug comes from
St.Widget
, sincethis.menu.hover
ererroneously returns false, even if the mouse is on the preview. I don't know whySt.Widget
has problems with setting the correct hover state, but as a workaround it seems that async_hover()
onthis.menu
before checking the current hover state fixes it:The St.Widget docs says about hover tracking:
Maybe I got luck and this is the right way to fix it, but as I don't have much knowledge about GNOME at all, I refrained from creating a pull-request. Would be great though if someone could confirm and fix this issue :)
Linux distribution and version
Zorin OS 17
GNOME Shell version
GNOME Shell 43.9
The text was updated successfully, but these errors were encountered: