Changing focus from a dialog box in openoffice causes 100% cpu usage

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open openoffice.org
2. Go to Insert->Table
3. Move mouse away from dialog box
4. Watch cpu usage skyrocket and system become unusable.

What version of the product are you using? On what operating system?
#uname -a
Linux newo 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 30 11:40:06 CEST 2008 i686
Intel(R) Pentium(R) M processor 1400MHz GenuineIntel GNU/Linux

openoffice-base 2.4.0-2

ghc 6.8.2-1

java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)

Running xmonad-darcs and xmonad-contrib-darcs, manually installed.

Original issue reported on code.google.com by obrien6...@gmail.com on 7 May 2008 at 7:06

[GoogleCodeExporter]

I also have this problem.

I am currently running Ubuntu Hardy (OpenOffice 2.4.0, GHC 6.8.2) with xmonad 
darcs 
and X11 1.4.2 compiled manually. This also occurred with Ubuntu Gutsy 
(OpenOffice 
2.3.0, GHC 6.6.1) with xmonad darcs and X11 1.4.2. This has happened for quite 
a 
while, so it’s not a recent bug in xmonad.

I set OOO_FORCE_DESKTOP to gnome and run gnome-settings-daemon from my 
.xsession. 
Unsetting OOO_FORCE_DESKTOP fixes the problem for me. obrien654j does not have 
OOO_FORCE_DESKTOP set, though.

Original comment by lit...@hethrael.org on 7 May 2008 at 7:28

[GoogleCodeExporter]

Just to add another data point, this is happening to me with an aging post-0.7 
darcs,
OOO_FORCE_DESKTOP not set, 6.8.2, 1.4.2.

It happens with every custom OO dialog. The Gnome ones like saving don't pop as
floating, so they don't trigger this bug.

Spawning a dialog that does cause the bug, then using mod+t to force it back 
into
tiling before moving the focus off of it makes it work fine.

Other floating windows (specifically the scratchpad terminal) don't seem to 
trigger
the bug either.

Spawning a dialog, tiling it, and then floating it again re-enables the bug.

Just some more behaviour for your consideration.

Original comment by Braden.S...@gmail.com on 16 May 2008 at 7:54

[GoogleCodeExporter]

More behavioural info.

I ran it with top on a suggestion from my roommate, and it showed that Xorg was
consuming ~65% CPU, xmonad 22-25%, and openoffice around 8%.

Also, the window border appears to be flying around between the windows on 
display,
and dzen was consuming 2% CPU, implying that the logHook was getting spammed as 
the
focus whirled between the windows.

Finally, the gnome-panel CPU bar was maxed out, and it was half dark-blue
interrupt-handler CPU time and half bright-blue user time.

Has anyone managed to spec the X events while this bug is active? I suspect it 
might
be illuminating, but I don't know how to make that happen. I probably should 
learn, I
suppose.

Original comment by Braden.S...@gmail.com on 16 May 2008 at 8:02

[GoogleCodeExporter]

I'd be curious to see if the patch I just sent to the xmonad list entitled

Fri May 16 15:09:47 CDT 2008  David Roundy <droundy@darcs.net>
  * quick hack to avoid infinite (but breakable) loop when using Tabbed.

has any effect on this.  The whirling focus you describe sounds suspiciously 
similar
to the alternating focus I get when using tabbed.  I don't see how the two 
could be
strictly related, but can certainly imagine that where there's a race condition
leading to an infinite loop there could be more than one way to trigger it. 

Original comment by daverou...@gmail.com on 16 May 2008 at 8:27

[GoogleCodeExporter]

I'm not sure if this is related or not, but I have a similar issue when 
bringing up 
the gnome-panel "workspace switcher" preferences. The preference will show up 
in my 
layout but the windows start rapidly rotating focus making things completely 
unusable. The only way that I can escape the mayhem is by repeatedly smashing 
Enter 
until I am lucky enough to have selected "Okay" on the preferences window.

Original comment by laylw...@gmail.com on 16 May 2008 at 8:36

[GoogleCodeExporter]

David: unfortunately, that didn't work. I updated to fresh darcs, the bug still
existed. Applied the patch and bug still exists. I made sure to touch my 
xmonad.hs
and mod+q, etc., it's for real.

laylward: I certainly hope they're related. The idea that xmonad could have been
harbouring several separate such bugs is hard to believe, really.

I think the next step is seeing if there's a spam of X events generated by this 
bug.
Given that Xorg was dominating the CPU usage, that seems likely. I'll probably 
figure
out how to do this tomorrow, if someone hasn't before then.

Original comment by Braden.S...@gmail.com on 17 May 2008 at 12:39

[GoogleCodeExporter]

See also issue #200, I've attached a previously posted patch there that works 
for me
- OOo still refuses to let me move the pointer out of the window, but it 
doesn't loop
and calms down as soon as I stop moving the mouse.

Original comment by Klaus.We...@gmail.com on 15 Aug 2008 at 9:46

[GoogleCodeExporter]

I have posted new findings about this bug in issue #200.

Original comment by k.kosciu...@gmail.com on 9 Sep 2008 at 11:21

[GoogleCodeExporter]

I can see this thread is quite old. Does it mean it has been fixed or abandoned?

I'm currently using XMonad 0.8.1-1.2, openoffice-base 3.1.0-2 and ghc 6.10.3-1 
and
have this problem, too.

I noticed that adding "className =? \"VCLSalFrame\" --> doFloat" to manageHook 
seems
to alleviate the problem in that the crazy focus jumps are easier to stop. It's 
not a
fix, however, just a help.

Original comment by kamil.st...@gmail.com on 12 Jul 2009 at 9:57

[GoogleCodeExporter]

See also #200 http://code.google.com/p/xmonad/issues/detail?id=200

Original comment by don...@gmail.com on 25 Oct 2009 at 10:41