gnome-panel autohides inconsistently

Thank you for your bug. Do you use some applet with a text entry? Could that be a problem similar to bug #4873 or bug #45974?

No, I don't have any text-entry applet on either panel.

About bug #45974 I doubt it's related: I did remove the default "menu" applet (the one with the Applications/Locations/System menus) and replaced it with the single-icon menu. However the same issue appears for both panels.

bug #4873 seems to be about a sliding panel. Mine isn't sliding, it hides "towards its edge" rather than "to the side". (It doesn't have the arrows either.)

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.

That looks like http://bugzilla.gnome.org/show_bug.cgi?id=128412 upstream then

Yes, there's probably a large class of similar issues depending on unusual ways of losing focus.

Looking at your thread, this seems to be at least influenced by metacity's focus behavior. I marked this as affecting metacity too, I think someone from there needs to at least take a look at it.

Yes, same thing here on Ubuntu 8.04 beta.

I was able to reproduce the bug using the procedure posted by Bogdan Butnaru above, but it's not the only time this happens, it's rather frequent actually.

It happens on two different computers:

- fresh install of Hardy Beta on a laptop computer

- upgrade from Gutsy to Hardy Beta on a desktop computer

Please note that I had Gutsy installed on the laptop and I never observed this behaviour. The same goes for the desktop computer, before the upgrade to Hardy I never had any problems with the panel autohide.

I support eros on his observation about hardy.
I use a small panel at the top right-hand corner of my desktop and a few drawers to hold my apps.
This used to be a very nice way to ensure the panel autohides on feisty and gutsy. (I still had a few instances in ANOTHER panel that would not autohide due to Tomboy)
Now, on hardy, the panel hides inconsistently, and I find myself having to "killall gnome-panel" quite a few times to force it to hide...
There are no entry boxes in the panel, just drawers to program icons, so I don't see why it won't hide anymore.
The OTHER panel that was behaving badly has been removed, so it is not to blame for the inconsistency.

I am quite baffled to see that this issue is still not resolved after more than a year!
I am part of those who want -actually, drool everyday to the thought of- ubuntu taking over the PC majority market share, but I am unhappy to say that these few bugs are not helping.
I am still wondering why this bug was given a "low" importance. It is part of the 'everyday use' of the Gnome environment. In other words, it is one of GNOME's most used functions by the users, and is also one of the first things they see when they are using GNOME. As such, any error in that panel, which is a main interaction idea- will take away from the excitement of users to use this Operating System. This error is not one that only advanced users of GNOME will encounter; on all operating systems, a reliable auto-hide function of the panels is usually the norm. I fail to see how we can make the software suite look professional if the first time a new user from the legacy OS tries to attempt his first modification by enabling autohide on his panel, he finds that contrarily to what he's used to, the panel decides every once in a while not to do as it's told.
Please do give this the importance it deserve. It is not just a customization issue, it is also, and more importantly, a reliability issue.

the bug is likely annoying for those who are using autohiding, but that's not the default configuration and that's not a data loss bug nor a crasher so not a high priority issue

the priority doesn't mean the bug is not annoying but there is thousand of desktop bugs open a very small team working on those so everything can't be worked in the same time

note also that there is not a lot of duplicates or comment on this bug which gives and indication that not so many users request for those

I'm having the same issue. I can reproduce the behavior every time though. I have a panel with a firefox launcher. I'm also using compiz (so the when I click on a launcher the icon does the zoom and fade out thing) It's easier to reproduce the bug when compiz is enabled.

To reproduce the problem:

> create an auto-hide panel with a firefox launcher
> click on the launcher and exactly when compiz does the icon zoom and fade out thing (or if not using compiz within 250ms) move the cursor to the middle of the screen where firefox will appear.
> If you keep the cursor where on the launcher for more than the compiz animation (i'm guessing around 250ms) and then move the cursor, the panel will always autohide.

This issue is really bothering me. It's basically making the auto-hide capability disappointing at best.

Hi all,

Just wanted to confirm this bug and add my own observations.

This behaviour can be re-created consistently with ALL icons/launchers on an auto-hidden panel. All you have to do is click on an item and quickly move your mouse out of the panel. I know the term "quickly" is subjective, but I would say its within normal usage patterns.

That is, this bug will happen when you click on something (e.g., to start a terminal), and move your mouse out of the panel within the next second (or so). If you linger for a bit and then move the pointer away from the panel, then (and only then) will the panel will behave correctly and auto-hide itself.

This happens in both the PCs that I have installed Ubuntu Hardy on.

More importantly (i think), this bug only happens when "the sexy stuff" is turned on (i.e., compiz, emerald). When Visual Effects (in System->Preferences->Appearance is set to "None", I was not able to reproduce the bug.

With Visual Effects set to "Extra", I was again able to consistently reproduce the bug. Seems likely that it has something to do with the compiz/emerald special effects. I'm no expert, but shouldn't this be easily solved by having a timer mechanism with regards to panel auto-hiding. That is, the panel (or X11 or gnome or whatever) polls the mouse position every second to see if it still has focus?

I agree with Tiede and Cinar Sahin. Personally, this bug is incredibly annoying. I know this bug (in itself) will not bring about the apocalypse but its like having a fire-ant crawling up your behind... its not gonna kill you but you definitely don't want it there either.

And please don't tell me the workaround is to switch-off auto-hiding and/or disable compiz. Dang it! I want my wobbly windows and I want my whole screen! :P

Thanks.

Hallo,

thanks to your reproduction of the bug and some research i found a way to fix the problem:

just uncheck the following option with gconf-editor: /desktop/gnome/interface/enable_animations

The panel will disappear as normal, but you wont have the zoom animation anymore ; /

Bug is alive and well still in Ubuntu Hardy, and unchecking enable_animations in gconf spectacularly fails to fix it here. Whether enable animations is checked or not, clicking on any icon in any panel and quickly moving the pointer away (like one normally does) from the panel still results in a persistant panel until I move the pointer into the panel and back out, which is very annoying behavior.

I nominated this for the one hundred paper cuts project.

When I first heard about the project, this was the bug I instantly was reminded of: it's bugged and annoyed me for well over three releases now and it still isn't fixed. I want to rely on gnome panel autohiding, but this way it is impossible. For now I work around it by manually hiding the panel, but this is a workaround at best.

This does not affect the default Ubuntu experience, which does not use autohidden panels. This is not a paper cut.

gnome-panel 1:2.26.0-0ubuntu7
Ubuntu 9.04

 - set top panel to auttohide
 - click the network manager icon, so that it's menu opens
 - click into some application window (I have Firefox)

Result: panel never hides
Expected: panel hides after timeout

About comment #16: This works with any menu created from the panel:
1)Right click on any part of the panel (w/ autohide enabled)
2)Move mouse onto context menu (if one isn't generated, try clicking somewhere else)
3)Move mouse off of menu onto desktop or an application window.

Still present in Karmic beta.

Still present in Karmic final too. Is it still a bug when you're so used to it that it feels like this is the way it's supposed to work? ;-)

Seriously, would this qualify as a "papercut"?

> Seriously, would this qualify as a "papercut"?

No. See comment 15.

same in gnome 2.32.0
(tested on the Ubuntu 10.10 desktop live CD)

The developer reaction to this basic bug is a joke, and is the reason why people are afraid of challenging quality levels offered by monopolies. Taskbar autohide functionality has existed in window managers for over a decade, and Linux can't get it right... Why even support the feature if it doesn't work?

It seems people have given up all together on this issue - out of "choice" perhaps?

Richard, this bug still bothers me every damn day. But, as you say, the reaction is a joke. I don't expect this to ever be fixed, as Gnome 2 is being deprecated (and with it my use of Gnome, FWIW).