638386 - Menus show but close on hover with compiz after returning from gnome-screensaver lock

Status: RESOLVED WORKSFORME

(Firefox :: Menus, defect)

Description

[Ariel Nemtzov]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110301 Firefox/4.0b13pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110301 Firefox/4.0b13pre

Once suspending my laptop running Linux Mint 10- Julia (GNOME) 64bit with Firefox 4 beta open, upon resuming my session when I click on any menu option (File, Edit, View...) they show but then trying to hover over the opened menu results in the menu disappearing. Moving the mouse back up to the menu bar shows the menu again but even if I try again to hover over the opened menu the same thing happens again.
Restarting Firefox 4 resolves this.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox 4 beta
2. Suspend session (in my case- close the lid)
3. Resume session (open the lid + log in)
4. Click on any item in the menu bar
5. Move mouse to try to select item from menu.
Actual Results:  
The menu that should be open allowing selection of one of the options disappears on hover of the mouse.

Expected Results:  
Menu remains open after click on menu bar until selection of option in menu.

Comment 1

[George Carstoiu]

Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110302 Firefox/4.0b13pre

I did see this issue but it's not 100% reproducible.

What is 100% reproducible and, I think is related to the issue reported above, can be observed using the steps below:

Steps:
1. Start Firefox
2. Suspend Ubuntu
3. Return from suspend
4. With mouse select "Bookmarks"
5. Go with the mouse to "Tools"

Actual results:
 - the background of "Tools" flashes but the menu doesn't open

Expected results:
 - the "Tools" menu opens

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Karl, do you have an idea?

Comment 3

[Karl Tomlinson (:karlt)]

What window manager is running?  Is compositing enabled?

(In reply to comment #0)
> 2. Suspend session (in my case- close the lid)
> 3. Resume session (open the lid + log in)

Is this suspend-to-ram?
Can you get the same password screen by locking the session (without suspending)?
Does the problem happen in that situation?

What about switching vt to a linux console and back (Ctrl-Alt-F2 and Ctrl-Alt-F7).  Does the problem happen then?

> 5. Move mouse to try to select item from menu.

Does using the arrow keys instead at this point work as expected?

I assume things are working as expected if firefox is restarted after resume.

If a new window is opened while the bug is active, do its menus work as expected?

Comment 4

[Ariel Nemtzov]

(In reply to comment #3)
> What window manager is running?  Is compositing enabled?

Using Compiz
 
> Can you get the same password screen by locking the session (without
> suspending)?

Yes

> Does the problem happen in that situation?

No
 
> What about switching vt to a linux console and back (Ctrl-Alt-F2 and
> Ctrl-Alt-F7).  Does the problem happen then?

No

> Does using the arrow keys instead at this point work as expected?

That was actually weird. Clicking on Bookmarks (for instance) allowed me to select a bookmark using up and down, but trying to move sideways to one of the other menus,just deselected the menus.
 
> I assume things are working as expected if firefox is restarted after resume.

Correct.
 
> If a new window is opened while the bug is active, do its menus work as
> expected?

Not only do its menus work as expected, it also fixes the buggy window!

I did find out something interesting, though. In the CompizConfig Settings Manager under Utility-> Workarounds there is a setting called Firefox Menu Fix, I have no idea what it does but when the bug is active, disabling and re-enabling that setting also seems to fix the menus.

Comment 5

[Henri Sivonen (:hsivonen)]

I see this using Compiz on Ubuntu 10.10 (64-bit) not only after waking up from hibernation but also after having had Firefox open for a long time without putting the computer to sleep or hibernation.

This affects both menubar menus and the context menu.

Comment 6

[Karl Tomlinson (:karlt)]

(In reply to comment #4)
> I did find out something interesting, though. In the CompizConfig Settings
> Manager under Utility-> Workarounds there is a setting called Firefox Menu Fix,
> I have no idea what it does but when the bug is active, disabling and
> re-enabling that setting also seems to fix the menus.

Interesting thanks.

In Gecko, menubar menus and context menus are given the same window type.

The "Extended Window Manager Hints" sees these menus as two different types of windows: _NET_WM_WINDOW_TYPE_DROPDOWN_MENU and _NET_WM_WINDOW_TYPE_POPUP_MENU.

Gecko tells the window manager that both its menubar and context menus are _NET_WM_WINDOW_TYPE_POPUP_MENU.  That workaround tries to detect firefox menus and treats both menu types (as well as possibly some other windows) as dropdown menus.

When that setting is enabled, it looks like compiz does some recalculation, which I assume is what is making things work again.
Creating a new firefox menu probably causes the same recalculation.

I assume that, once working, the menus continue to work after disabling that setting again?  Menus in a subsequent new Firefox window may look different.

I'm not clear whether the recalculation is done on disabling the setting.
I gather that disabling wasn't enough to fix the menus?

I'm getting the impression that this recalculation is resetting something for which compiz has stale data.  Gecko may be unique in keeping around its menu windows for long periods of time.  (Other apps may recreate windows on demand.)

Does a quick suspend and immediate resume cause the bug?

Comment 7

[Ariel Nemtzov]

(In reply to comment #5)
>I see this using Compiz on Ubuntu 10.10 (64-bit) not only after waking up from
>hibernation but also after having had Firefox open for a long time without
>putting the computer to sleep or hibernation.

I also see this happening occasionally. 


(In reply to comment #6)
> I assume that, once working, the menus continue to work after disabling that
> setting again?

Correct

> I'm not clear whether the recalculation is done on disabling the setting.
> I gather that disabling wasn't enough to fix the menus?

Actually, after reading this I checked and only disabling appears to fix the issue too. Also with the setting disabled I couldn't seem to recreate the bug. Which is a good thing, I think.

> Does a quick suspend and immediate resume cause the bug?

Not sure what you mean there. Every time I've recreated the bug to answer one of the questions here, I either closed the lid of y laptop, effectively suspending (those are my power settings), or suspending through the Shutdown menu. Either way I almost always brought it back to life right after the suspending was complete. I think that answers your question.
BTW, I noticed that the bug also affects the Search Plugins' dropdown selection.

Comment 8

[Karl Tomlinson (:karlt)]

(In reply to comment #7)
> Also with the setting disabled I couldn't seem to recreate the bug.
> Which is a good thing, I think.

Yes, that's good to know.

> Either way I almost always brought it back to life right after the
> suspending was complete. I think that answers your question.

Yes, thanks.

What is puzzling is that the whole idea of suspend/resume is that the system returns in the same state as before.  Apparently something during that process is triggering the problem.  There may be some services stopped and restarted or input devices temporarily disabled, ... , but it's strange that anything would affect windows.  Perhaps it could be suspending the GPU which is the trigger.

Can you and Henri indicate your graphics drivers in use, please?

Comment 9

[Ariel Nemtzov]

(In reply to comment #8)
> Can you and Henri indicate your graphics drivers in use, please?

Not sure how to obtain which driver I'm using but I do have an Intel GM965 Chipset

Comment 10

[Karl Tomlinson (:karlt)]

/var/log/Xorg.0.log may contain some version strings, but the hardware vendor is a good place to start, so let's see whether Henri also has Intel hardware.

Comment 11

[Henri Sivonen (:hsivonen)]

(In reply to comment #8)
> Can you and Henri indicate your graphics drivers in use, please?

[ 95098.473] (II) LoadModule: "nvidia"
[ 95098.473] (II) Loading /usr/lib/xorg/extra-modules/nvidia_drv.so
[ 95098.475] (II) Module nvidia: vendor="NVIDIA Corporation"
[ 95098.475]    compiled for 4.0.2, module version = 1.0.0
[ 95098.475]    Module class: X.Org Video Driver
[ 95098.475] (II) NVIDIA dlloader X Driver  260.19.06  Mon Sep 13 04:31:43 PDT 2010
[ 95098.475] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

[133819.601] (II) NVIDIA(0): Setting mode "nvidia-auto-select"

The driver comes in the nvidia_current package. The GPU I have is GeForce GT 210 Silent.

The computer is Shuttle SX58H7 (Intel X58 Express board). Waking this computer from hibernation with default kernel params worked on Karmic broke on Lucid. Currently on Maverick, to get the computer to wake from hibernation properly, I need to make Grub pass the acpi_sleep=nonvs parameter to the kernel. Dunno if that's relevant, but mentioning it just in case.

This is pretty annoying and at least the occurrence without hibernation is recent, so nominating as a blocker hoping for .x+. (I don't dare to suggest stopping 4.0 ship over this.)

Comment 12

[Karl Tomlinson (:karlt)]

Thanks.  Video driver seems unlikely to be the problem then.

Does disabling "Firefox Menu Fix" workaround the problem for you, Henri?

Comment 13

[Karl Tomlinson (:karlt)]

(In reply to comment #11)
> at least the occurrence without hibernation is recent,

Do you suspect this is a regression across Firefox versions?

Comment 14

[Ariel Nemtzov]

(In reply to comment #10)
> /var/log/Xorg.0.log

And based on Henri's post, I think this is what you wanted:
[    59.571] (II) LoadModule: "intel"
[    59.572] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[    59.572] (II) Module intel: vendor="X.Org Foundation"
[    59.572] 	compiled for 1.9.0, module version = 2.12.0
[    59.572] 	Module class: X.Org Video Driver
[    59.572] 	ABI class: X.Org Video Driver, version 8.0

I actually tend to feel that since updating to the last beta (haven't tried RC yet, will get to that later) it actually felt like it was a little harder to reproduce the bug.

Comment 15

[Henri Sivonen (:hsivonen)]

(In reply to comment #12)
> Does disabling "Firefox Menu Fix" workaround the problem for you, Henri?

By default, the Firefox Menu Fix is disabled on Ubuntu. I noticed that I'm unable to provoke the problem by hibernating and waking up right after. I'll try toggling the workaround when I manage to see the problem again. I'll go out to run some errands and leave my computer hibernated to see if that's enough to provoke the problem.

(In reply to comment #13)
> (In reply to comment #11)
> > at least the occurrence without hibernation is recent,
> 
> Do you suspect this is a regression across Firefox versions?

I haven't spent serious time running Firefox 3.6 using Compiz, because I bought this computer after 3.6 branched, so I don't know if this is a regression from 3.6. Hibernation on my computer was broken until less than a week ago, so in February I didn't use hibernation at all and shut down my computer for the night. Yet, without using hibernation, I first saw this problem maybe 3 weeks ago or so even though I've been using self-built m-c snapshot on this computer for a year, which is why I think this is recent or has gotten worse recently. I didn't report this three weeks ago, because I thought it had gone away when I pulled again from m-c.

Now that hibernation works on my computer, I've seen this ofter over the past week both triggered by hibernation *and* by spontaneous occurrence after having Firefox open for a few hours. After RC1 froze, I've been using a self-built opt build from the RC1 changeset.

Comment 17

[B.J. Herbison]

Longstanding issue, see bug 507269, bug 616833, and bug 631518.

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking.

Comment 19

[Karl Tomlinson (:karlt)]

Comments in bug 507269 indicate toplevel window focus/activation issues.

Comment 20

[Henri Sivonen (:hsivonen)]

On my system, if the Firefox Menu Fix is not enabled when the problem occurs, enabling it fixes the problem right away (without having to relaunch Firefox). (Tested with an occurrence that didn't happen right away after waking up from hibernation but a relatively short time after.)

Comment 21

[Henri Sivonen (:hsivonen)]

(In reply to comment #20)
> On my system, if the Firefox Menu Fix is not enabled when the problem occurs,
> enabling it fixes the problem right away (without having to relaunch Firefox).
> (Tested with an occurrence that didn't happen right away after waking up from
> hibernation but a relatively short time after.)

This also works in the other direction: If the Firefox Menu Fix is enabled when the problem occurs, disabling the fix makes the problem disappear (without having to relaunch Firefox).

Comment 22

[Henri Sivonen (:hsivonen)]

I'm suspecting that this can also occur when the computer doesn't go to sleep but when the energy saver powers off the display.

Also, it appears that when menus break, the Awesomebar pop-up breaks, too (doesn't show at all).

Comment 25

[Thopter]

I'd like to confirm that I'm experiencing this bug as well. Ubuntu 10.10, Firefox 4 official release, Dell Inspiron 1525 laptop. I do not run a screensaver, nor do I lock or suspend my laptop. I do have my screen set to turn off after 10 minutes inactive, however the last 2 times I've encountered this bug, the first time was after I turned the screen back on. I hit the bug, then found a tip to minimize and restore firefox, which worked. The second time it happened, the screen had not turned off. The "minimize trick" seems to be a temporary fix. I have not heard about this "menu fix," so I do not believe I have it enabled.

Comment 26

[0.zer0]

This is definitely an issue of using FF4 with Compiz. I don't use "Suspend" or "Hibernate", so I can't comment on those reports. I can, however, say that I haven't experienced this issue while using Metacity. I can also confirm that, while using Compiz, minimizing then restoring the browser window "fixes" the bug until the next idle period. 
My PC's specs: Compaq Evo D510 CMT; P4 @ 2Ghz; 1.5GB RAM; AGP 4X GeForceFX 5200; Ubuntu 10.04LTS
Renderer: GeForce FX 5200/AGP/SSE2 (NVIDIA Corporation)
Driver: 2.1.2 NVIDIA 173.14.22

Comment 31

[river226]

I would like to report expirencing this Bug myself. Ubuntu 10.04 64-bit, with a Minefield build of Firefox. I have been expirencing it since The beta, and always encounter it after my computer goes to screensaver and I return. So far the minimize trick, or simply going to a differnt window if I have one open works.
The issue seems to effect how everything works, search, bookmarks, menu, and awesomebar.

Comment 32

[Karl Tomlinson (:karlt)]

http://cgit.compiz.org/compiz/core/commit/?id=30a92d8a060d79181a28840d7c66428ef431200c

WFM with compiz fix.