After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 128412 - panel fails to auto-hide when mouse moves out during pointer grab
panel fails to auto-hide when mouse moves out during pointer grab
Status: RESOLVED OBSOLETE
Product: gnome-panel
Classification: Other
Component: general
2.17.x
Other All
: Normal minor
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 135616 315185 358129 381430 453745 528696 603365 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-12-03 01:22 UTC by Scott Jones
Modified: 2020-11-06 20:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
Probable fix (1.97 KB, patch)
2004-08-27 09:09 UTC, Arvind S N
needs-work Details | Review
Panel configuration dump, relative to Comment #14 (145.97 KB, text/plain)
2005-07-24 11:40 UTC, Nicolas Raoul
  Details

Description Scott Jones 2003-12-03 01:22:47 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
Comment 1 Tom Lamm 2003-12-04 17:25:09 UTC
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
Comment 2 Luis Villa 2004-01-02 22:49:12 UTC
I'll stick with Vincent's assessment in the other bug- this is still 
around. Thanks for taking a look at the bugs, Tom.
Comment 3 dcolling 2004-01-03 09:39:32 UTC
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.
Comment 4 Bart Martens 2004-02-19 19:21:36 UTC
I just reproduced the problem on Fedora Core 1 with gnome-panel-2.4.0-3.
Comment 5 Mark McLoughlin 2004-02-27 17:58:56 UTC
*** Bug 135616 has been marked as a duplicate of this bug. ***
Comment 6 dolsson5 2004-03-17 02:30:49 UTC
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.
Comment 7 Dimitrios 2004-05-23 03:39:29 UTC
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 :(
Comment 8 Arvind S N 2004-08-27 09:09:06 UTC
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 9 Mark McLoughlin 2004-09-14 09:23:24 UTC
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
Comment 10 Mark McLoughlin 2004-09-14 09:24:08 UTC
(Oh, I committed the first part of the patch - the bit that resets the source
ids when removing the timeout)
Comment 11 Mark McLoughlin 2004-09-14 09:47:33 UTC
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.
Comment 12 Havoc Pennington 2004-09-14 15:13:00 UTC
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.
Comment 13 Mark McLoughlin 2004-09-14 16:26:17 UTC
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 ...)
Comment 14 Nicolas Raoul 2005-07-24 11:36:30 UTC
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.
Comment 15 Nicolas Raoul 2005-07-24 11:40:17 UTC
Created attachment 49672 [details]
Panel configuration dump, relative to Comment #14

Result of gconftool-2 --dump /apps/panel > /tmp/panel.conf
Comment 16 Leo Lopes 2005-08-09 16:51:36 UTC
In the meantime, a workaround (obvious for some, not for others):

killall -HUP gnome-panel
Comment 17 Vincent Untz 2005-08-18 09:51:00 UTC
Nicolas: I can't reproduce your bug. Maybe you're opening the applications menu?
If so, then it's the same bug.
Comment 18 Sebastien Bacher 2007-02-01 10:02:51 UTC
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.
..."
Comment 19 Vincent Untz 2007-05-25 21:38:54 UTC
*** Bug 381430 has been marked as a duplicate of this bug. ***
Comment 20 Vincent Untz 2007-05-26 11:45:52 UTC
*** Bug 358129 has been marked as a duplicate of this bug. ***
Comment 21 Vincent Untz 2007-06-29 13:45:59 UTC
*** Bug 315185 has been marked as a duplicate of this bug. ***
Comment 22 Vincent Untz 2007-07-05 12:58:35 UTC
*** Bug 453745 has been marked as a duplicate of this bug. ***
Comment 23 Vincent Untz 2008-04-20 11:37:02 UTC
*** Bug 528696 has been marked as a duplicate of this bug. ***
Comment 24 Alex Launi 2008-11-23 19:54:49 UTC
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?
Comment 25 Brad 2009-10-02 18:36:47 UTC
We're really stretching the definition of "new" here. Still present in 2.28.x
Comment 26 Vincent Untz 2010-01-14 02:34:21 UTC
*** Bug 603365 has been marked as a duplicate of this bug. ***
Comment 27 om111 2010-04-11 00:15:15 UTC
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.
Comment 28 David Balažic 2010-10-10 22:31:55 UTC
same in gnome 2.32.0
(tested on the Ubuntu 10.10 desktop live CD)
Comment 29 fuzzybyte 2010-12-02 14:07:12 UTC
still on gnome-panel 2.32.1
(tested on Arch Linux)
Comment 30 André Klapper 2020-11-06 20:21:04 UTC
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.