Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 229137 - Alt-Tab or Ctrl-Alt-arrow with focus on GNU Emacs freezes metacity/gnome-panel
Summary: Alt-Tab or Ctrl-Alt-arrow with focus on GNU Emacs freezes metacity/gnome-panel
Status: CLOSED DUPLICATE of bug 224611
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-panel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-18 04:21 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-02-27 17:45:43 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2007-02-18 04:21:03 UTC
Description of problem:
Annoyingly often, when switching between applications with Alt-Tab or when
switching between virtual desktops with Ctrl-Alt-arrows or Ctrl-Alt-numbers, the
window manager will stop working.  The application loses focus, but you can
still move the mouse around.  It's just that clicks don't work any more, and
auto-hide panels are no longer unobscured.  Alt-Tab and Ctrl-Alt-keys no longer

Sometimes, Ctrl-Alt-F1, then Ctrl-Alt-F7 brings the window manager back to life.
 More often, after this it returns with a blanked-out screen, and a keystroke
and/or mouse movement is needed to unblank.  Sometimes, not even that will work,
and I need to log in on VT1 and killall metacity to get a functional desktop
again.  IIRC there was at least one situation in which this didn't work.

I've noticed this on my notebook a while ago (just before FC7T1), but I thought
it might be something specific to it.  Today I've updated rawhide on my main
desktop and booted into it, and ran into the same problem.  Both are x86_64,
originally installed as rawhide just before FC6, having tracked daily rawhide
updates since then.

Version-Release number of selected component (if applicable):

How reproducible:
At random

Steps to Reproduce:
1.Start a gnome session
2.Open firefox, emacs, gnome-terminal, etc, on various virtual desktops
3.Switch between virtual desktops or between applications
Actual results:
The window manager eventually freezes

Expected results:
It shouldn't

Additional info:

Comment 1 Alexandre Oliva 2007-02-18 09:51:21 UTC
I've found out that restarting gnome-panel also restores the desktop to a
functional state.  Also, the 'mouse movement' needed to unblank above is one
that takes the mouse cursor over one of the panels, nothing else will do.  So
this is pointing at gnome-panel, rather than metacity.


It appears that, if I always use the mouse to switch from one desktop to
another, and to switch from one window to another, I never trigger this problem.

Comment 2 Alexandre Oliva 2007-02-18 15:08:20 UTC
This problem is most common when I switch to a VT where a full-screen 1280x1024
firefox is running, but I have seen it happen in other cases as well.

Comment 3 Alexandre Oliva 2007-02-19 04:18:57 UTC
It looks like it's strongly related with the use of emacs-22.0.93-6.fc7. 
Whenever the focus is on Emacs, Alt-Tab or Ctrl-Alt-Arrow triggers the problem,
as the pop-up to select the active application or workspace fails to pop up. 
Ctrl-Alt-number selects workspaces reliably (since there's no pop-up?).  I
couldn't find any keystroke to switch focus away from an Emacs window to some
other window on the same virtual desktop :-(

Comment 4 Alexandre Oliva 2007-02-19 07:51:59 UTC
FWIW, a build of GNU emacs --without-gtk does not expose this problem.  So it
might be a bug in Emacs, not in gnome-panel, after all, but it's a bit scary
that misbehaving applications can freeze the entire desktop like this.

Comment 5 Andrew Gormanly 2007-02-20 15:02:53 UTC
This appears to be the same as or related to bug 224611 and can be worked-around
by disabling assitive technologies, if you don't need them.  Mark this as a dupe?

Comment 6 Chip Coldwell 2007-02-23 14:39:57 UTC
(In reply to comment #5)
> This appears to be the same as or related to bug 224611 and can be worked-around
> by disabling assitive technologies, if you don't need them.  Mark this as a dupe?

Very likely.

Alexandre: please try disabling assitive technologies, log off, log back on and
see if the problem goes away.  If so, we'll close this as a duplicate of 224611.

BTW, 224611 shows up on RHEL 5 and probably FC-6 also.  The difference seems to
be that FC-7 ships with assitive tech switched on by default.


Comment 7 Alexandre Oliva 2007-02-27 17:45:43 UTC
Yes, the problem appears to go away.  Duping...

*** This bug has been marked as a duplicate of 224611 ***

Note You need to log in before you can comment on or make changes to this bug.