I can confirm that this occurs in Compiz, too. Switching to Compiz to fix what appeared to be a system-wide bug seemed to work, but then it cropped up again. Whoops.
Have disabled assistive technologies and seem to be going fine now.
Local situation: have dual-head (using nvidia glue instead of xinerama), with an emacs window open full-time with "always on visible workspace" enabled. Frequently have other emacs windows open as well.
Using emacs 22.2.1 GTK+ 2.14.1, started experiencing freezes when changing between workspaces, alt-tabbing between windows, or resizing (or title-bar-right-clicking) emacs, starting after upgrading to 8.10. System would sometimes reawaken after (a) three-eight seconds, (b) hitting numlock, or (c) ctrl-alt-F1 ctrl-alt-F7.
System was running fine for the duration: system monitor was ticking over (and not showing any additional load), remote ssh was fine, mouse was still active (though stuck on its last image). Would often come back with the alt key wedged down (according to emacs, at least) and needing to be tapped to bring the keyboard back to normal. (Have seen reports that caps lock has been left on. May be significant that I have ctrl and caps swapped.)
Nothing at all in any logs.
Suspected hardware, swapped a -lot- around before discovering that using Compiz (single-head) instead of Metacity (dual-head) seemed to have fixed it. Then went dual-head again, turned always-on-visible-workspace back on, and hit death. Realised that emacs seemed to be the common factor, found this thread, disabled assistive technologies, and voila.
Other data points: emacs22-x is fine, emacs-snapshot (23.0.60.1 GTK+ 2.14.3) is fine.
Thomas Thurman could well be on the money that the emacs event loop is throwing GTK for a spin. AT is obviously also monitoring events; is there perhaps a race condition between emacs22 and at-spi?
(have reconsidered blaming Compiz, so sorry for the mail traffic. this appears to be a duplicate of 287577; any objections to marking it so and adding at-spi to the packages?)
I can confirm that this occurs in Compiz, too. Switching to Compiz to fix what appeared to be a system-wide bug seemed to work, but then it cropped up again. Whoops.
Have disabled assistive technologies and seem to be going fine now.
Local situation: have dual-head (using nvidia glue instead of xinerama), with an emacs window open full-time with "always on visible workspace" enabled. Frequently have other emacs windows open as well.
Using emacs 22.2.1 GTK+ 2.14.1, started experiencing freezes when changing between workspaces, alt-tabbing between windows, or resizing (or title-bar- right-clicking) emacs, starting after upgrading to 8.10. System would sometimes reawaken after (a) three-eight seconds, (b) hitting numlock, or (c) ctrl-alt-F1 ctrl-alt-F7.
System was running fine for the duration: system monitor was ticking over (and not showing any additional load), remote ssh was fine, mouse was still active (though stuck on its last image). Would often come back with the alt key wedged down (according to emacs, at least) and needing to be tapped to bring the keyboard back to normal. (Have seen reports that caps lock has been left on. May be significant that I have ctrl and caps swapped.)
Nothing at all in any logs.
Suspected hardware, swapped a -lot- around before discovering that using Compiz (single-head) instead of Metacity (dual-head) seemed to have fixed it. Then went dual-head again, turned always- on-visible- workspace back on, and hit death. Realised that emacs seemed to be the common factor, found this thread, disabled assistive technologies, and voila.
Other data points: emacs22-x is fine, emacs-snapshot (23.0.60.1 GTK+ 2.14.3) is fine.
Thomas Thurman could well be on the money that the emacs event loop is throwing GTK for a spin. AT is obviously also monitoring events; is there perhaps a race condition between emacs22 and at-spi?
(have reconsidered blaming Compiz, so sorry for the mail traffic. this appears to be a duplicate of 287577; any objections to marking it so and adding at-spi to the packages?)