GNOME Bugzilla – Bug 152169
Temporary Lock Ups on All Window Controls
Last modified: 2009-08-15 18:40:50 UTC
Distribution: Gentoo Base System version 1.5.3 Package: metacity Severity: major Version: GNOME2.7.92 2.8.x Gnome-Distributor: BreakMyGentoo.net Synopsis: Temporary Lock Ups on All Window Controls Bugzilla-Product: metacity Bugzilla-Component: general Bugzilla-Version: 2.8.x Description: Description of Problem: Using the 2.8.4 version of metacity, with about 10 virtual desktops and switching via keyboard or mouse between desktops the entire windowing system appears to lock up, disallowing text to be typed into terminal windows, hotkey workspace switching, or switching via the mouse. However, windows can still be moved around using the mouse, just nothing will take focus. Happens repeatedly and in no predictable fashion. Steps to reproduce the problem: 1. Use the system for a few minutes. 2. Switch virtual desktops. Not have it work. 3. Keep trying, clicking every button, eventually.. let's up. Actual Results: System is temporarily unusuable. Expected Results: Shouldn't be happening. How often does this happen? 8-15 times a day throughout a normal workday. Additional Information: Been noticing this since 2.8.3. Switching back to 2.8.2 which didn't have this problem. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-09-08 10:48 ------- Unknown platform unknown. Setting to default platform "Other". Unknown milestone "unknown" in product "metacity". Setting to default milestone for this product, '---' Setting to default status "UNCONFIRMED". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
I'm noticing now that this happens in 2.8.2 as well. I think this is part of the problem: It seems to happen if I select via keyboard the workspace that I'm already viewing. I have my 2nd viewspace set to Alt-2. If I'm already in Workspace 2, it locks up when I press Alt-2. From that point I can manipulate windows but it is as if Metacity is locked into only understanding mouse clicks as window movement, resize, etc commands.
Any chance you could get us a verbose log? To do so: 1. Reduce your desktop to as few windows as possible to reproduce the bug 2. Run METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace 3. On stdout metacity will print the name of the logfile 4. Reproduce the bug as quickly as possible 5. Kill the metacity you started above to stop the logfile from growing any longer 6. Compress the logfile and attach it to this bug report
Also, does it depend on which Alt key is pressed? (There appears to be a Metacity bug made visible by an xorg change that is dependent on which modifier is used; it's a long shot, but I thought I'd ask).
I've tried various things I can think of--race on focus window and workspace switch, use of right alt key, looking up old gtk bugs on grabs like (e.g. bug 92085 or bug 82128) to see if they shed any light on the matter--and then tried to see if I could use those guesses and situations to find if it would help me duplicate somehow. But I can't figure out how to cause this at all. I also thought about bug 143851, which this might be a duplicate of. I'm really curious (besides a log which would be the most helpful) about any options you might have set (click/sloppy/mouse focus, autoraise, reduced resources, choice of theme, etc.).
Created attachment 31446 [details] Log file of this bug
I went ahead and followed your instructions. A. Yes I am running Xorg. And using the ALT key to switch workspaces. When I change the modifier to my Windows key the problem goes away. B. I am using click-to-focus, no autoraise, no reduced resources. It happens regardless of theme. I reproduced it by switching back to ALT keys and starting the logging as you said. I went to my first workspace, then back to my second. While on my second I pressed my ALT-2 key combination to switch workspaces, but as I was already there it shouldn't have done anything. Instead it locks the same way. To get it to unlock I simply click somewhere on the desktop. Thanks for your attention to this. Also, I am using the left ALT key in almost all cases.
Thanks for the log and the extra info. Interesting to hear that it is specific to the Alt key. What is the output of running 'xmodmap' on your machine? Also, does this "keyboard freeze" only happen with one of the two alt keys, or can you get the freeze to happen after using either one?
Note that this is almost certainly a duplicate of bug 151554...
Does Soeren's patch in bug 151554 fix this issue for you?
No response, so I'm going to assume that the fix works. Please reopen if that isn't the case.