Closed Bug 779900 (MenuBug) Opened 12 years ago Closed 2 years ago

Version varies per user: Right-click and drop-down menus and drag-and-drop fail

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: JimiJames.Bove, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120720200044

Steps to reproduce:

I upgraded to Firefox 14 with PulseAudio installed on my system. For others, it was FF13 or 12 or even 4.


Actual results:

Firefox became unable to load more than 1 layer of the UI. Right-clicking, menus, and click+dragging was all impossible. Deleting ~/.pulse-cookie fixes the problem (until ~/.pulse-cookie comes back), but even without PulseAudio installed on the system, the issue still makes a comeback when I click on anything at all in the File-Edit menus (including history, bookmarks, web developer features, and even the preferences). Performing the same operations within the sidebar does not cause this bug. Restarting Firefox fixes the bug until it's reactivated by ~/.pulse-cookie or by using a menu item.

It's all explained in greater detail here: https://support.mozilla.org/en-US/questions/932643
Read the OP, the first post mentioning ~/.pulse-cookie, and my (Cadeyrn's) second post. That paints the full picture.


Expected results:

The menus should be clickable, and PulseAudio should be usable, without deactivating Firefox's ability to load any menus.
URL: https://support.mozilla.org/en-US/que...
Severity: normal → major
Component: Untriaged → Menus
Alias: PulseAudioMenuBug
Hardware: x86_64 → All
I guess that only video/audio is accessing pulseaudio
Component: Menus → Video/Audio
Product: Firefox → Core
It's not a problem with PulseAudio or the Video/Audio. It's a problem with menus. When you click on an menu item in Firefox, an operation is run that the ~/.pulse-cookie file also runs upon launching Firefox. This operation is the cause of the bug. PulseAudio technically isn't related to this bug--it's simply a means we have to discover the real problem.
Component: Video/Audio → Menus
Product: Core → Firefox
(In reply to Matthias Versen (Matti) from comment #1)
> I guess that only video/audio is accessing pulseaudio

Plugins and theme/widget code also has audio playback.

Given this is an issue with menus, my first guess would be that this is related to the use of libcanberra in the widget code that is used for playing back theme sounds when menus are opened, etc.
Actually, I researched that exact bug's report here on bugzilla. It can be fixed by disabling IPv6, but that didn't fix it for me. On top of that, no package named libcanberra or file named libcanberra.so is on my computer. I can only conclude this is a separate bug.
We need to stop thinking this has anything to do with sound. The fact is with PulseAudio uninstalled, and all of its traces deleted, this bug still happens when any Firefox menu item is clicked on. The only relation to PulseAudio this bug has is that the issue is caused by something the Firefox menus and the ~/.pulse-cookie file have in common.
I removed PulseAudio but this bug still happens.
This is also on Launchpad: https://bugs.launchpad.net/bugs/1020198
The title of this bug should be changed to, e.g. "14.0.1: Right-click and drop-down menus fail"
Alias: PulseAudioMenuBug → MenuBug
Summary: Upon updating to a given version (random for each victim) and every subsequent version, Firefox becomes unable to open any menus (right-click or otherwise) or drag any items because of ~/.pulse-cookie or usage of the File-Edit-View-etc. menus → Version varies per user: Right-click and drop-down menus fail
Summary: Version varies per user: Right-click and drop-down menus fail → Version varies per user: Right-click and drop-down menus and drag-and-drop fail
(In reply to Adam Porter from comment #7)
> This is also on Launchpad: https://bugs.launchpad.net/bugs/1020198

If that bug is specific to Unity, it might not be the same bug as this one. This bug is confirmed to affect a Kubuntu user (me) and a Xubuntu user. Also, my brother (who uses Unity) has a bug that's just like this, only his menus come back when he right-clicks his tabs. See if that works on this one.
As I posted on that Launchpad bug, it is not specific to Unity.  The original reporter uses Unity, but it affects KDE and Xfce users as well.

When I use 14.0.1, right-click and drop-down menus work until I use them once.  Then they utterly fail, even on tabs.
This is now happening in Firefox 15 as well.  Just now, after having Firefox running for a few days, as soon as I posted a comment on the Launchpad bug saying that I thought I had found an extension causing the bug, menus stopped working.  They vanish before they can finish drawing, anywhere in the browser, content or chrome.  The only fix is to restart Firefox, and then it's just a matter of time before they inexplicably fail again.
I confirm that it's happening in Firefox 15.
I use Xubuntu 12.04.
Hey, I recently have exactly same issue on my Desktop. It happened randomly with all Firefox 13+. But this bug didn't come up on my Thinkpad X60 Laptop. Both boxes are running _PURE_ Openbox on Debian Wheezy 64bit system. I think the only noticeable difference of both is the graphic card. Desktop has NVidia GT520 card powered by Open-source driver meanwhile Laptop has Intel card on board.
My laptop also has Intel HD graphics, and it still has this problem, so I don't thing that's it.
My desktop has AMD ATI HD 4670 card, so graphic card is not problem.
Jay, are you using the Global Menu Bar integration extension?  I seem to have tracked the bug down to this.  When I disable it I don't have the bug anymore.  I never had the bug until Firefox 14, and I've been using firefox-globalmenu since long before Firefox 14.  I don't know if that extension is shipped in distros other than Ubuntu, but if I understand correctly, that extension works with KDE, Unity, etc, not just one DE.
Disabling that extension works on my end as well.
I didn't use Global Menu Bar extension. Actually I don't even know what it is. :P

BTW, I've switched to Google Chrome browser for nearly a month, which is working well on my Desktop.
Thanks for tracking this down. Marking invalid (addon bug)
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Disabling Global Menu Bar integration extension doesn't solve the problem.
Since Jay has had this problem without using the extension, perhaps this bug shouldn't be closed.  Maybe the extension is a symptom of the problem rather than the cause.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
After upgrading to Firefox 14 long ago, I started having this problem on my work desktop. I'm quite sure it was 14 that first had this problem. It always fixed itself when I downgraded back to 13.

Anyway, I since then reinstalled my work desktop with 64 bit Debian (was 32) I didn't have this problem for a long time. Now, finally today (after many months) I started having this problem again with 16.0.1. Thankfully, this time googling the problem I found threads with the actual same problem and the .pulse-cookie fix and finally found this bug report.

Interestingly, I had PulseAudio uninstalled over a month ago so I just had that dead cookie file since I didn't have the PA server loaded and only now it caused this problem.

Immediately after removing the cookie and restarting Firefox everything started working again.

I only have Adblock Plus, Firebug and PDF Viewer extensions installed. And naturally the Java plugin and Adobe Flash. Disabling or removing any of the extensions did nothing before nor disabling any plugins. Creating a completely new profile did fix the issue for a short time but it usually started failing in a few hours anyway.

This bug can't be closed yet for sure. At least I have a workaround now so I can continue working after I hit it.

Though I must admit I'm using the Iceweasel fork on Debian but it seems unrelated to the bug itself.
Since writing the comment above, I hit the problem again. This time I didn't have .pulse-cookie at all and just restarting the browser helped - for now.

Seems I'm stuck with this again until I create a new profile.
^Again, I'm extremely sure that this is because even without .pulse-cookie, the bug happens when you use a menu.
I think this problem is related to a bogus timestamp generated by
misbehaving clients.

Can people who suffer from this problem take a look at ~/.xsession-errors and see
if there are lines about timestamp in an event is well into the future, etc?
(Or maybe an unexpected timestamp value of zero.)

GTK library seems to get stuck with a bogus timestamp well into the future, and
once that happens, ff/tb and other programs may suffer.

Case in point 1:

A buggy version of unity window manager seems to have generated
such events with bogus timestamps, and affected ff/tb.
https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/1016386
https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/1010466

Case in point 2:
Users of X11 XIM input mechanism including many Chinese users and myself (I use Japanese) 
suffer from the symptoms mentioned here due to the bogus timestamps in X11 events passed around during XIM interaction: core libX11 has produced bogus timestamps(!)
https://bugzilla.mozilla.org/show_bug.cgi?id=787943
https://bugs.freedesktop.org/show_bug.cgi?id=39367

Your case?

Your problem(s) may be related to different clients, if your usage does not fit
the scenario above.  Tough luck :-(
My first suggestion is to look into window manager log to see
if the system recognizes there are issues X events with bad timestamps.
(~/.xsession-errors is most likely file.)

How you can zero in in the culprit, i.e. a misbehaving client, after
you know that there is timestamp issue, is another matter.

I wish GTK library which seems to be affected by such bad timestamp has a
history mechanism and an easy hook to figure out who sent the incorrect timestamp
after the fact. Right now, after the bogus timestamp is thrown into the system
and we notice ff/tb began malfunctioning, there is not much we can do.
All we know is that someone sent the incorrect timestamp.
But who is hard to find unless the use of gdb to place a breakpoint at
key locations of some programs and/or some heavy-weight debugging session is performed.

Because of the nature of the problem, it may be a good idea 
to report one's distribution (and OS version),
and the used desktop (and possibly the window manager if you know).

I was using Debian GNU/Linux (Linux debian-vbox-ci 2.6.39-2-686-pae, taken from uname -a output) and gnome when the problem caused by incorrect time stamp generated by bugs in
XIM routines of libX11 hit. The window manager is metacity.
The problem caused by XIM has subsided by a patch submitted is applied to libX11 so far.

But I am sure there can be other causes for warped timestamps.

Hope this helps.
I'm on Xfce 4.6.2 on Debian stable using xfwm. I have very few apps open. Mostly Firefox, Thunderbird, The GIMP, rxvt-unicode, Skype and xfce4-panel and related items.

How come Firefox is the *only* app affected by this bogus timestamp? Not even my Thunderbird get caught by this. No other GTK app misbehaves like Firefox does when this happens.

I don't see any related errors (timestamp or Firefox) when this happens in .xsession-errors. It was fine for a few weeks but now it keeps doing that in under 2 minutes and is getting really frustrating. I need to change my browser at work to get my job done, I can't keep restarting Firefox every 2 minutes.

I'll try closing other apps to see if anything affects how long it takes for it to break.
(In reply to Toni Spets from comment #26)
> I'm on Xfce 4.6.2 on Debian stable using xfwm. I have very few apps open.
> Mostly Firefox, Thunderbird, The GIMP, rxvt-unicode, Skype and xfce4-panel
> and related items.
> 
 ...

> I don't see any related errors (timestamp or Firefox) when this happens in
> .xsession-errors. It was fine for a few weeks but now it keeps doing that in
> under 2 minutes and is getting really frustrating. I need to change my
> browser at work to get my job done, I can't keep restarting Firefox every 2
> minutes.
> 

Maybe xfwm may not produce the type of errors which gnome's window manager does, and in a different place if any (not in .xsession-errors).

A comment to the XIM related bug  contains an explanation about
a short program to dump events and timestamps.
If you can post your result of running the program 
when the problem happens (or actually you have to run it contnuously and
capture the events around the time the problem is noticed)
in bugzilla entry for bug 787943,
Karl, the poster of the comment, who seems to have done a lot of work on this issue may be able to offer his insight. In my case, his observation that libx11 may have some uninitialized field when creating event in handling XIM events clued me in the cause.

But one thing is strange. In my case, it was thunderbird that mostly
got disrupted by this problem since events generated during keyboard input for
Japanese characters using XIM caused bogus timestamps.

But you say thunderbird is NOT affected in your case. This suggests 
 - either some external program generetes bogus time stamps (but in this case
   both TB and FF are likely to be affected), 
 - or FF generated bogus timestamp on its own due to an addon (plugin) or combination of them.
 - other possibilities that I can't think of right now.

Can you try to run FF in safe-mode (i.e., without any addon being loaded) and see
if it suffers the problem in a few minutes or not?

TIA
> A comment to the XIM related bug  contains an explanation about
> a short program to dump events and timestamps.

Sorry, somehow URL was missing about this comment.
https://bugzilla.mozilla.org/show_bug.cgi?id=787943#c13
I tried closing different programs but the problem recurred very fast. In the end I rebooted my system and Firefox has been working fine since with everything open as they were before.

My system uptime was around 29 days (including Xorg). I think this is very related. I don't keep my home system always on and I never hit this bug there. I'll try rebooting just Xorg next time if it's some X component that starts failing after a long time.
(In reply to Toni Spets from comment #29)
> My system uptime was around 29 days (including Xorg). I think this is very
> related. I don't keep my home system always on and I never hit this bug
> there. I'll try rebooting just Xorg next time if it's some X component that
> starts failing after a long time.

Yes, the wraparound of server time (32bits) may have something to do with the problem. 

The following comment to Bug 787943 has an explanation about the wraparound of server time. (See the third last paragraph.)
https://bugzilla.mozilla.org/show_bug.cgi?id=787943#c56
I can confirm that when I triggered the input method to type in Firefox, this issue came up instantly. After unset the GTK_IM_MODULE locally (so not messing up with other apps that need it), as a Chinese guy suggested, it was 'fixed'. I don't know the root cause though..

Tested on Firefox 20.0.
(In reply to Jay Wu from comment #32)
> I can confirm that when I triggered the input method to type in Firefox,
> this issue came up instantly. After unset the GTK_IM_MODULE locally (so not
> messing up with other apps that need it), as a Chinese guy suggested, it was
> 'fixed'. I don't know the root cause though..
> 
> Tested on Firefox 20.0.

Are you using XIM input method?
(GTK_IM_MODULE=xim, for example?
If so, you may be bitten by the bug in X11 (XIM module in X11 generates bogus timestamp [uninitialized memory is used.])
(In reply to ISHIKAWA, chiaki from comment #33)
> Are you using XIM input method?
> (GTK_IM_MODULE=xim, for example?
> If so, you may be bitten by the bug in X11 (XIM module in X11 generates
> bogus timestamp [uninitialized memory is used.])
Yeah, I was and am still using XIM input method everywhere. Luckily input method can work on Firefox without this GTK config. But this issue still happens very occasionally (roughly once per day) after applying this workaround.
(In reply to Jay Wu from comment #34)
> (In reply to ISHIKAWA, chiaki from comment #33)
> > Are you using XIM input method?
> > (GTK_IM_MODULE=xim, for example?
> > If so, you may be bitten by the bug in X11 (XIM module in X11 generates
> > bogus timestamp [uninitialized memory is used.])
> Yeah, I was and am still using XIM input method everywhere. Luckily input
> method can work on Firefox without this GTK config. But this issue still
> happens very occasionally (roughly once per day) after applying this
> workaround.

Have you tried replacing X11 library as suggested in


> https://bugs.freedesktop.org/show_bug.cgi?id=39367

https://bugzilla.mozilla.org/show_bug.cgi?id=787943#c54
https://bugzilla.mozilla.org/show_bug.cgi?id=787943#c55

After replacing the X11 library, I am experiencing this bug only after about 28/29 days or so. [After the 32 bit timestamp wraps around.]
@ISHIKAWA,

I haven't tried your patch on X11 library yet. And sorry, I have no time to test it for now.

BTW, Firefox is the only victim of this timestamps issue. So I just thought Mozilla would do something to avoid this kind of XIM bugs. :P
(In reply to Jay Wu from comment #36)
> @ISHIKAWA,
> 
> I haven't tried your patch on X11 library yet. And sorry, I have no time to
> test it for now.
> 
> BTW, Firefox is the only victim of this timestamps issue. So I just thought
> Mozilla would do something to avoid this kind of XIM bugs. :P

That was what I thought myself. But it looks that the interaction between GTK library and Thunderbird library is rather intricate and this bug seems to be difficult to fix :-(
[And it doesn't help that GTK people are more interested in doing wonderful things in the later versions of the library while widely used GTK2 library seems to be in maintenance only mode and not much is being done on the version.

But I think your point of making mozilla software less susceptible to the
type of bug is important [any client that creates bogus timestamp outside X11 library bug itself can wreak havoc against mozilla software.]
Let us hope something will be done over the long run to make TB, FF and other
software from Mozilla community to be more robust in the face of this type of external bug.

Like Jay Wu, I was bitten this bug and once this happens TB and FF are not usable at all, and it is puzzling to see TB and FF are affected while many other
software on the GNOME desktop seem to work just fine.
I always has this bug on KDE, other DEs just fine.
I have been having this problem since August 2012. Many users have already reported the bug many times. The bug, however, still happens now. Although it is not related to FF, I think Firefox should fix it, because other programs work fine. I'm using  FF 22.0 on Arch Linux x86_64 with Openbox.
Depends on: 787943
I can confirm this bug on Debian 32bit, and also with newest 35.0 firefox, tried many firefox versions now

I have had this bug for 2-3 years now, very annoying bug

only happens on my debian 32bit boxes, it isnt broken on ubuntu 64bit at work

but on all debian boxes it is broken for me
right click menu stops working after 3-5mins , I disabled all plugins and made new profile with no luck

then I have to restart firefox to get right click menu to work

I use:
adblock+
flashblock

can someone try to duplicate?

It's a very annoying bug, because I cant close tabs when menu doesnt work
cant get into settings either, so browser gets useless daily.. :(

Hope you will fix it, and make it a more severe priority, I run debian stable
there should be no such bugs here... it's almost as bad as a segfault for me, the program is unuseable daily

thanks
I have also tried deleting all .*pulse* files, if the problem was related to pulseaudio as someone suggested, didn't help
The bug furthermore happens on multiple machines, all debian stable

I have had 3 laptops with the problem now, all debian stable (3-5 years old now).

Debian GNU/linux 7.0 is it currently, still got the problem, it has been there for 2-3 years at least
but its getting more common somehow now

it happened after one version release of firefox im pretty sure as someone suggested, maybe after 14.0 as he said....

I had no problems, then one day, problems every day since, on all machines (they all got forced upgraded their firefox...)

a bug introduced in a new firefox under certain conditions seems it could be the clue maybe?
One last thing: problem happens both with ratpoison window manager(which firefox also breaks horribly in its fancy preview thing in 35.0 firefox) , and blackbox window manager

right click menus don't work in either, not on pages, not in top menus in firefox

if you want to replicate, try firefox 35.0, ratpoison wm, adblock+, flashblock plugins  on a debian stable , you will get problems within 3-5mins when you open 5-10 tabs (even with 1 tab open it happens I think)
The issue seems to be limited to Linux only, I got a windows machine that doesn't show this behavior on same newest firefox!

It doesn't seem to happen on ubuntu either, haven't seen it there once

happens all the time on debian! , but also with custom firefox both nightly and newest stable tarball
so is not a dist related problem it seems, seems a nasty FF bug that is hard to trace

bug happens even if I run firefox as "root" :-) , with no plugins and no profile
For the record, after I switched to Fedora this problem disappeared completely.

The only difference was the software stack how it's on Fedora (version and packaging wise) and that I use the "real" Firefox package rather than Iceweasel I used previously. The software I had/have open has pretty much stayed the same.

Has this issue been magically fixed/avoided somewhere in the X.org stack?
The patch I explained in comment 35
https://bugzilla.mozilla.org/show_bug.cgi?id=779900#c35

is in official Xorg source tree (since around the beginning of 2014) and I believe it has replaced the buggy version under Debian and other distribution by now.
I'm also experiencing this problem on ubuntu with Firefox 45.0.2.

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"

$ aptitude search pulse | grep "^i"
i   gstreamer1.0-pulseaudio         - GStreamer plugin for PulseAudio           
i A libcanberra-pulse               - PulseAudio backend for libcanberra        
i   libpulse-mainloop-glib0         - PulseAudio client libraries (glib support)
i   libpulse0                       - PulseAudio client libraries               
i A libpulse0:i386                  - PulseAudio client libraries               
i   libpulsedsp                     - PulseAudio OSS pre-load library           
i   pulseaudio                      - PulseAudio sound server                   
i A pulseaudio-module-bluetooth     - Bluetooth module for PulseAudio sound serv
i A pulseaudio-module-x11           - X11 module for PulseAudio sound server    
i   pulseaudio-utils                - Command line tools for the PulseAudio soun
Hello,

I am experiencing this problem, and I wanted to add what I have learned about it, because it's completely different from the ideas so far in investigating this problem. Bear with me, because the explanation is a bit long-winded :).

First, some background. I am using Firefox 55.0.2 on Ubuntu Mate 16.04.2. The symptoms are that none of the menus for any extensions, or even the firefox main menu will work. Right-clicking does not drop a menu anywhere, including for links on web pages. If I use F10 to show the menu bar, clicking on most of the menus (only the top level items show) simply causes the menu bar to go hidden again, and whatever action I chose does not occur. The exceptions to this so far are that the Help menu actually brings up help and (if I haven't forgotten) the History menu brings up the history.

In addition, clicking on the close box of the window appeared to cause firefox to lock up (this turns out to be a clue).

Here is what I have learned. This is related to my monitor set up. I have my main monitor (vga right now, don't ask...), and also a television hooked up via HDMI. In my monitor setup, I have the screens mirrored, so that both show the same thing.

The VGA monitor is set as my main monitor, but sometimes, not always, when the tv is turned on, it will take over as primary (which is a huge bug on it's own). Then, when the tv is turned off again, the only remaining monitor comes back as the primary monitor. BUT it gets confused - in the Monitor Preferences dialog, the single screen shows way off to the side, as if the OS can't figure out where the screen is.

I believe that as a result of this issue, Firefox is actually drawing the menus somewhere I can't see - the menu position calculation is thrown off by whatever is happening with the display confusion.

My evidence for this is that when I click on the close box, Firefox appears to lock up. But, I eventually noticed that there was something on the side of my screen, which turned out to be the very edge of a window. I was able to drag it onto the screen - it was the 'Close All Tabs?' confirmation dialog!

In addition, once I figured this out, I turned on the tv again, and the display settings went back to looking correct, and the Firefox menus all started working correctly again.

I am still a newbie at linux, but I am happy to provide any additional information that someone might want - you will just have to give me good instructions on how to get what you want.

I hope this helps someone.

Hey Jim,
Can you still reproduce this issue or should we close it?

Flags: needinfo?(JimiJames.Bove)

I personally haven't seen this bug in years, and I still use both Firefox and PulseAudio. So in my case at least, it's fixed.

Flags: needinfo?(JimiJames.Bove)

Closing as "works for me" based on comment 50.

Status: REOPENED → RESOLVED
Closed: 12 years ago → 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.