[X11] tooltips aren't removed when cursor leaves window
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
People
(Reporter: ossman, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0
Steps to reproduce:
- Move another window so it overlaps Firefox
- Move the mouse cursor over Firefox so it moves over an element with a tooltip
- Move the cursor further so it moves over the overlapping window instead of Firefox
Actual results:
Tooltip is shown
(and element is styled as if it is hovered)
Expected results:
Tooltip should disappear
(and element should be styled in a neutral state)
|
Reporter | |
Comment 1•2 years ago
|
||
This bug has been around for ages, but I got annoyed enough today to report it.
Issue is seen on Fedora 38 with Xorg. Have not tested with Wayland.
Issue can be a bit finicky. Happens most reliably if you sweep the cursor so that you pass the Firefox element and move the cursor to the overlapping window faster than the tooltip timeout. It will then pop up the tooltip, even though the cursor is over the non-Firefox window.
Can not reproduce this with other GTK 3 or GTK 4 applications, so it doesn't seem to be a general toolkit issue.
|
||
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•2 years ago
|
|
||
Comment 3•2 years ago
|
||
I can reproduce this bug (firefox nightly, X11, xfce, xfwm), and in my case, it is only triggered when the firefox window is out of focus. Can the original reporter confirm this?
|
|
||
Comment 4•2 years ago
|
||
(In reply to fanzhuyifan+github from comment #3)
I can reproduce this bug (firefox nightly, X11, xfce, xfwm), and in my case, it is only triggered when the firefox window is out of focus. Can the original reporter confirm this?
If so, I believe this is a duplicate of 148624, and should be fixed by D187418. The fix works for me for this bug.
|
|
Reporter | |
Comment 5•2 years ago
|
||
No, it also happens when Firefox is focused. However, once it loses focus the tooltip is closed.
I tested this by tagging another window as "Always on top", then did the same steps as in the initial description, but with Firefox focused.
|
|
||
Updated•2 years ago
|
|
|
||
Comment 6•2 years ago
|
||
For me, right now this only happens (on firefox-nightly on linux with xorg) if and only if both of the following hold:
- The other window is tagged as "always on top", so the firefox window does not lose focus even when the cursor leaves the firefox window and moves to the other window (this could be confirmed by testing to see that firefox still receives user inputs)
- The environment variable
MOZ_USE_XINPUT2is set to 1 and not 0.
If 1 does not hold, this issue should be fixed by the fix for 148624, since tooltips are no longer displayed when the firefox window is not focused/active.
Could the original reporter confirm if these two conditions are also necessary and sufficient for them?
Thanks!
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 7•2 years ago
|
||
Neither 1 nor 2 is required for me when testing Firefox 118 on Fedora 38 here. Happens with a normal gnome-terminal in front of Firefox.
I think I saw that Fedora unconditionally enables XInput 2 in their builds, though. So 2 might actually be active. MOZ_USE_XINPUT2 is not in my normal environment, but about:support shows MOZ_USE_XINPUT2 | 1.
If I download Nightly from Mozilla, then I can indeed only reproduce the issue if both 1 and 2 hold.
Facing this issue when MOZ_USE_XINPUT2 is set, indeed annoying. I have enabled 'hot corners' feature in my Linux Mint to get the workspace overview when mouse goes to top left corner. But if firefox is maximized state in the current workspace, the the firefox tab overview(tooltip) of the first tab(in the top left corner) comes, and it is not removed even if I change the app/workspace.
|
||
Comment 9•8 months ago
|
||
Btw, I haven’t seen this issue occurring in years anymore on my system. Maybe it has been a KDE Plasma side fix?
|
|
||
Comment 10•8 months ago
|
||
(In reply to Maximilian Böhm from comment #9)
Btw, I haven’t seen this issue occurring in years anymore on my system. Maybe it has been a KDE Plasma side fix?
It's X11 only. Plasma moved to Wayland by default already, that may be the factor here unless you use explicitly X11.
|
|
Reporter | |
Comment 11•8 months ago
|
||
I can confirm that the issue still exists on GNOME X11.
But not as much, though. I now need to have the "Always on top" window, as mentioned in comment 6. MOZ_USE_XINPUT2 is still 1, so I'm not sure what has changed.
|
|
||
Comment 12•8 months ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #10)
(In reply to Maximilian Böhm from comment #9)
Btw, I haven’t seen this issue occurring in years anymore on my system. Maybe it has been a KDE Plasma side fix?
It's X11 only. Plasma moved to Wayland by default already, that may be the factor here unless you use explicitly X11.
I’m using Plasma 6.3 on X.Org. This bug got fixed at least a year ago on Plasma 5 for me.
Description
•