GNOME Bugzilla – Bug 134563
Auto-hide problems when using applet context menu
Last modified: 2020-11-06 20:22:31 UTC
My panel (2.4.2) is at the bottom of the screen and is set to "auto-hide". When I click on an item in the panel that produces a pop-up menu and select an item in the menu that does not lie above the panel, the desired action is performed and my mouse is left outside of the panel. However the panel does not hide as expected. The panel will only hide if I bring the mouse back inside the panel and then out again. For example, right click on the border of window list or clock. For me, the pop-up menu lies sufficiently high up so that the "About..." item does not lie above the panel. The panel remains open as I move up the menu to "About..." (as expected) but still remains open after I select "About..." and the menu disappears. The same occurs if windows are grouped in my window list and I select one from the pop-up menu.
This problem is not as consistently reproducible as I had first reported. But I still find it occurs most of the time.
Leslie: when you move your mouse on the panel to unhide it and then move it quickly out the panel (before the panel has finished unhiding), does the panel stay unhidden? I can't reproduce using gnome-panel 2.4.2 and HEAD.
Vincent: The problem you describe does not occur. That is, if I move my mouse quickly to the edge where the panel is hidden and then quickly away before the panel fully appears, the panel does indeed go back to being hidden. (I had this problem previously, before my system people upgraded to panel 2.4.2.) My problem as first described is different: after selecting from a large menu that the panel created, the panel remained unhidden. This problem occured consistenly for over a day before I reported it. It then dissapeared for a while and then reappeared. Sadly I cannot say why. I do have many windows, however (Mozilla, terminal, xdvi, acrobat reader, gnomecal, gpmail). I am using panel 2.4.2, tasklist 2.4.2, and Gnome 2.4.0.
Thanks for your answer. I still can't reproduce with gnome-panel 2.4.2. Weird. I'll ask someone to try to reproduce.
I can't reproduce this with the latest panel. Please re-open if you can reproduce this with 2.8.0 or later. Thanks
I am re-opening this because the problem still consistently occurs. I am now using gnome-panel 2.8.1 and window-list 2.8.1 as Mark McLoughlin suggested. (The version of gnome as a whole is 2.6 however and will not be upgraded to 2.8 for some time.) My panel is at the bottom with size of 56 pizels. It is set to autohide; the "expand" and "show hide buttons" options are *not* selected. The window list applet is set to "always group windows". I bring the mouse near the bottom of the screen and the panel appears. I click on grouped item in the task-list and a menu appears which often does not overlap the panel. When I select a window from such a menu, the window appears, the menu dissapears, but the panel remains unhidden.
Leslie: I can not reproduce. Do you know when you'll be able to upgrade to an entire GNOME 2.8 desktop to test it again? Is it always reproducable with the steps you gave?
Vincent: Here are the steps that seem to consistently reproduce it (but I have been fooled before about "consistently"). Create a session with no open windows and just a 56 pixel panel set to autohide, expand, and no buttons at the bottom of the screen. The panel contains Clock 2.8.1, WindowList 2.8.1 with always group windows set, a few launchers, and the main menu. Restart the X-server and login. Start Gnome terminal from the menu and iconify it. Start another Gnome terminal from the menu and iconify that. Now press the "terminal (2)" entry in the window list and select the terminal entry in the popup menu that comes first. The cursor should not be over the panel at this point. The terminal window appears and the panel does not hide. Currently we have Fedora Core 2 with GNOME 2.6, with Panel 2.8.1 installed. Our systems staff will probably not upgrade to GNOME 2.8 until March or April at the earliest with the Fedora Core 4 release. If necessary I can have them put up a single computer for testing with Fedora Core 3 and GNOME 2.8.
I think I got a similar bug: my panel doesn't auto-hide if I lock/delete an applet. The problem is that we don't push/pop the autohide disabler with applet context menus (we do it for launchers).
*** Bug 109630 has been marked as a duplicate of this bug. ***
*** Bug 300739 has been marked as a duplicate of this bug. ***
This bug is still present in Panel 2.10.1 with Gnome 2.10.
Still present in Panel 2.14.3 with Gnome 2.14.3 in Ubuntu 6.06. I find this highly annoying... actually my mind already makes me push the cursor to the panel automatically in regular intervals so it won't stay unhidden. :) Would be great if somebody fixed this. See also in Ubuntu: https://launchpad.net/products/gnome-panel/+bug/58181
From https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/58179 "... I have the regular Ubuntu panels. I set both of them to autohide. However, they stay unhidden when I do the following: 1. Move cursor over panel item 2. right-click (or left-click, depending on item) to open a context menu 3. Move cursor out of panel and context menu 4. Click to close context menu What happens: Panel now stays unhidden until I push the cursor in and out again. What should happen: Panel should hide when the context menu closes. ..."
Also reported against various gnome versions in Fedora: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159073
I would suggest that the panel should either listen for pointer movement until it hides again, or periodically poll for the position of the pointer, or somehow listen for close events of the menus of its applets.
Created attachment 92755 [details] [review] Proposed patch This patch adds a timeout call if INFERIOR type leave_notify event is emited. The problem for this bug relies on applet codes from what I understood. Clicking on the panel applet emits leave-notify signal. However that time, since pointer is in container, panel auto hide queue is not used. Since some applets don't propagate mouse clicks on menu items, gnome-panel does not receive another leave-notify signal. This patch, just adds one more timeout call for leave notify. It's not a total solution for this problem. But at least I'm having less unhid panels with this patch, so wanted to share it.
Comment on attachment 92755 [details] [review] Proposed patch >Index: panel-toplevel.c >=================================================================== >--- panel-toplevel.c (revision 10580) >+++ panel-toplevel.c (working copy) >@@ -3637,6 +3637,8 @@ > > if (toplevel->priv->auto_hide && event->detail != GDK_NOTIFY_INFERIOR) > panel_toplevel_queue_auto_hide (toplevel); >+ else if (toplevel->priv->auto_hide && event->detail == GDK_NOTIFY_INFERIOR) >+ g_timeout_add (toplevel->priv->hide_delay, (GSourceFunc) (GSourceFunc) panel_toplevel_auto_hide_timeout_handler, toplevel); > > if (GTK_WIDGET_CLASS (panel_toplevel_parent_class)->leave_notify_event) > return GTK_WIDGET_CLASS (panel_toplevel_parent_class)->leave_notify_event (widget, event);
I found three bugs in this upstream tracker that describe the same problem: http://bugzilla.gnome.org/show_bug.cgi?id=529785 http://bugzilla.gnome.org/show_bug.cgi?id=302574 http://bugzilla.gnome.org/show_bug.cgi?id=134563 Maybe someone can have a look at them and decide wheter two are just duplicates. Thanks.
I looked at all three bugs Martin listed. Using 2.24.1-0ubuntu2.1 (Ubuntu 8.10) I was unable to reproduce these two: http://bugzilla.gnome.org/show_bug.cgi?id=529785 http://bugzilla.gnome.org/show_bug.cgi?id=302574 But I could reproduce http://bugzilla.gnome.org/show_bug.cgi?id=134563 I don't /think/ they are duplicates. 302574 may be fixed as there have been no reports for a couple of years. The original reports for 529785 and 134563 seem to be distinct. Comment #1 in 529785 actually seems to be reproducing bug 134563, not bug 529785. To reproduce 134563: Set panel to auto-hide. Right-click on an applet (tried with power manager, network monitor and system monitor), then click on About, a background application, or the desktop. Result: menu disappears, panel stays visible. Expected result: menu disappears, panel hides. Slightly different way to reproduce 134563: Set panel to auto-hide. Open sufficient windows/applications that some are are grouped. Click on a group, select a window from the menu. Result: menu disappears, panel stays visible. Expected result: menu disappears, panel hides.
Still happening in gnome-panel 2.26.0-0ubuntu4 in Ubuntu 9.04 Beta.
*** Bug 496954 has been marked as a duplicate of this bug. ***
Still happening in gnome-panel 2.30.0, GNOME 2.30.2, Fedora release 13
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.