GNOME Bugzilla – Bug 128412
panel fails to auto-hide when mouse moves out during pointer grab
Last modified: 2020-11-06 20:21:04 UTC
Steps to Reproduce: 1.) Create Auto-Hide Panel 2.) Move Mouse over panel so panel is visible. 3.) Press "Alt-Tab", keeping "Alt" pressed so that the "Alt-Tab" pop-up remains visible. 4.) Move Mouse out from panel while holding the "Alt". 5.) Release "Alt" and panel remains visible. This sounds like it wouldn't happen very often, but using a setup like this, it has happened to me many times today (I must be alt-tab happy). Thanks. -Scott
This bug has the same affect as Bug 128455, but describes a different set of actions to reproduce it. It may be a duplicate, or may be same symptom/different problem. Tom Lamm
I'll stick with Vincent's assessment in the other bug- this is still around. Thanks for taking a look at the bugs, Tom.
Ah-hah! This probably explains why I get a stuck panel several times a day. I'm also quite Alt-Tab happy. I confirmed that this happens on my Mandrake 2.4.0 desktop.
I just reproduced the problem on Fedora Core 1 with gnome-panel-2.4.0-3.
*** Bug 135616 has been marked as a duplicate of this bug. ***
I'm running Red Hat Enterprise WS 3. My autohide panel sticks open everytime I use a menu from the panel: gnome menu; right-click menu. If I go back and wave my pointer over the panel, it closes.
Any chance of getting this fixed? i'm having a shit loads of problems with the auto-hidden panels in my Fedora Core 2 which is quite a shame, sort of disapointment that gnome 2.6 comes with such usability problems :( not to mention that if this ever gets fixed, it will brobably reach our hands in 6-9 months in Fedora Core 3 or something :(
Created attachment 31004 [details] [review] Probable fix Removing the check to see if we have the pointer on the panel fixes the problem of Alt-Tab. But would like to know if people would want the panel to be shown when Alt-Tab is happening. We really need to strike a middle path as focusout events are already over the moment you press Alt-Tab and after releaseing Alt-Tab panel does not receive any events. hence it gets stuck.
Comment on attachment 31004 [details] [review] Probable fix The fix isn't right - we need that contains_pointer() check or we'll get the panel hiding at times it shouldn't
(Oh, I committed the first part of the patch - the bit that resets the source ids when removing the timeout)
Just to recap - this is a very specific bug: 1) Move the mouse over the panel 2) Hold Alt and hit tab to get the Alt-Tab popup 3) Move mouse out from the panel 4) Release Alt What's going on is that we never get a LeaveNotify because metacity grabs the pointer when displaying the Alt-Tab popup. So, moving to metacity - I'm not sure I understand why its neccessary to have a pointer grab for the tabpopup. It does two things AFAICS: 1) Makes the tabpopup modal - i.e. you can't do anything while the popup is visible 2) It makes ButtonPress close the window (2) doesn't seem incredibly useful or logical and making it not modal doesn't seem like a terrible idea ... maybe the popup would get confused if you start closing windows or switching workspaces by other means ... Anyway, moving to Metacity - if we must have the pointer grab during Alt-Tab, then this is a WONTFIX.
Mark, I'm not sure I buy your analysis - when metacity starts the grab, the panel should get a LeaveNotify caused by the grab. Someone is probably ignoring LeaveNotify caused by grabs. This is why you can't do that.
Hmm, I'd forgotten about NotifyGrab - good point, thanks. We should be able to do something with that, but it needs some thought. We don't want to hide on NotifyGrab, and in this case we won't get a NotifyUngrab. Also need to consider the grab implicit in a ButtonPress. (All this for such a tiny corner case ...)
This bug happens to me at least every ten minutes, but in a different form: I have two autohiding panels, one at the left and one at the bottom. This is how to reproduce the bug: 1) Move the mouse to the left of the screen, to unhide the left panel, 2) Staying on the left panel, move to the bottom, to unhide the bottom panel, 3) Staying on the left panel, move up from the bottom panel, 4) The bottom panel does not autohide, that is the bug. This is probably because the left panel keeps the focus, and the bottom panel never get it. Note that if I do the same manipulation exchanging left and bottom, then I get the same results: the left panel does not autohide. I insist that this panel configuration happens often, in my opinion: - win32-like bottom bar - favorite applications buttons bar on the left Because the "Gnome main menu" button lies in the bottom left corner, my mouse is always around, and the bug happens very often. I thought this bug was similar to 128412, so here it is. If you think it is a different bug, just tell me and I will create a new one. I attach the result of panel conf dump, just in case. Running Gnome 2.10.0 Ubuntu. Gnome is so good, it is a pity to still have this bug... Thanks ! Nicolas.
Created attachment 49672 [details] Panel configuration dump, relative to Comment #14 Result of gconftool-2 --dump /apps/panel > /tmp/panel.conf
In the meantime, a workaround (obvious for some, not for others): killall -HUP gnome-panel
Nicolas: I can't reproduce your bug. Maybe you're opening the applications menu? If so, then it's the same bug.
Ubuntu bug looking similar to that one: https://launchpad.net/gnome-panel/+bug/82504 "... After a bit of playing with the panels I found at least one reproducible case where the panel remains opened: 1) First set at least one panel to autohide. (I don't think it matters, but mine has "hidden size" and "hide delay" set to zero.) 2) Start Firefox, and resize it's window to smaller than the screen. 3) With Firefox having the focus, make the panel unhide by sliding the mouse over it. (Don't click it!) Keep the cursor there so the panel stays unhidden. 4) Press F11 on your keyboard. This will make Firefox go in full-screen mode, which means it goes above the panel. (Note that the panel is always on top of normal windows.) 5) Move the mouse out of the (hidden) panel's surface (to the middle of the screen, for instance). Keep it there. 6) Either (a) press F11 again to make Firefox a window or (b) press Alt-Tab to switch to another (not-fullscreen) window. (This will make Firefox loose its "on top" status.) Result: Now the panel is visible, but the mouse is not on it. Expected result: The panel should have hidden itself at step (4) or at step (5) -- because the cursor is no longer on it. ..."
*** Bug 381430 has been marked as a duplicate of this bug. ***
*** Bug 358129 has been marked as a duplicate of this bug. ***
*** Bug 315185 has been marked as a duplicate of this bug. ***
*** Bug 453745 has been marked as a duplicate of this bug. ***
*** Bug 528696 has been marked as a duplicate of this bug. ***
This bug is still around 4 years later. I'm on GNOME 2.24 and my autohidden panel is frequently staying since I use <alt><f1> to show the applications menu often. Can we at least mark it confirmed?
We're really stretching the definition of "new" here. Still present in 2.28.x
*** Bug 603365 has been marked as a duplicate of this bug. ***
I can confirm this bug for 2.28.1 too. I applied part of the patch from Arvind's https://bugzilla.gnome.org/attachment.cgi?id=31004 panel_toplevel_queue_auto_hide (PanelToplevel *toplevel) { g_return_if_fail (PANEL_IS_TOPLEVEL (toplevel)); if (!toplevel->priv->auto_hide || - panel_toplevel_contains_pointer (toplevel) || panel_toplevel_get_autohide_disabled (toplevel)) return; if (toplevel->priv->unhide_timeout) g_source_remove (toplevel->priv->unhide_timeout); The only negative effects I noticed were, * Right clicking on an item in the window list, or clicking one of the menus hides the panel, and * clicking on an item in the window list (where doing so causes the window to minimise) hides the panel. So if anyone else really wants to get rid of the problem the bug causes you may want to apply the patch anyway. Personally I would much prefer these side effects than the problem of the panel not autohiding.
same in gnome 2.32.0 (tested on the Ubuntu 10.10 desktop live CD)
still on gnome-panel 2.32.1 (tested on Arch Linux)
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.