Bug 229137

Summary:	Alt-Tab or Ctrl-Alt-arrow with focus on GNU Emacs freezes metacity/gnome-panel
Product:	[Fedora] Fedora	Reporter:	Alexandre Oliva <oliva>
Component:	gnome-panel	Assignee:	Ray Strode [halfline] <rstrode>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	coldwell
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-02-27 17:45:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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
work.

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):
metacity-2.17.5-1.fc7

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.

gnome-panel-2.17.91-6.fc7

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.

Chip

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 ***