xmonad spins in a tight loop changing focus back and forth

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Open office writer
2. Open a dialog window, say CTRL-O for open file
3. Move pointer from floating window to main window changing focus

This happens with other apps as well.

What is the expected output? What do you see instead?

I expect to see the focus changed to main application window. Instead the
focus spins back and forth between two windows, and xmonad does not respond
to keypresses. They are not discarded though, as when one of the windows is
closed, xmonad "executes" all actions related to key events sent before.

What version of the product are you using? On what operating system?

ghc 6.8.2
xmonad from darcs (0.7)
open office 2.4.0
debian linux

Please provide any additional information below.

While the xmonad changes the focus back and forth, the window borders
flicker, yet application windows have no problems in updating their state
(say while hovering pointer over a button). Button clicks seem to be added
to event queue but they get through to application only after xmonad
finishes processing all the queued focus changes.

Original issue reported on code.google.com by k.kosciu...@gmail.com on 15 Aug 2008 at 7:24

[GoogleCodeExporter]

This is the same as issue 188.

Original comment by lit...@hethrael.org on 15 Aug 2008 at 7:43

[GoogleCodeExporter]

Could you try the attached patch? I had sent this previously to the mailing 
list but
it doesn't appear to have been applied. I tried your reproducing steps and 
everything
is behaving as expected.

Do you have the UpdatePointer module active?

Mailing list posting copied below:

[xmonad] patch: fix looping due to unnecessary window crossing events

This patch fixes a race condition reported by David Roundy (Subject:
Re: [xmonad] darcs patch: quick hack to avoid infinite (but breakable)
loop when...):

> The isMouseFocused hack introduced a race condition where if you click on a
> tab to select a window, and then move the mouse down before the new window
> is selected, the focus will alternate between the previously-focused and
> newly-focused windows in an infinite loop.  This loop can be broken by
> moving the mouse up to the tab area, but it's pretty unpleasant.  This race
> condition is easily triggered on my laptop (and presumably on any older
> computer running bloated applications like firefox).

What is happening is apparently:

a) click on tab causes window B to be focused (with mouseFocused true)

b) mouse moves down into old window A, queueing an enter event for A

c) xmonad maps window B, appearing under the mouse pointer

d) enter event for B gets queued

e) xmonad handles enter event for A, causing it to be focused

f) xmonad maps window A, appearing under the mouse pointer

g) enter event for B gets queued

... goto (c)

The change is to ignore crossing events when the pointer is not currently in
the window being reported as entered, for example due to having left it
already, or if the windows were reshuffled due to keyboard commands.

-Klaus

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

Attachments:

• xmonad-core-ignore-obsolete-crossing-events.dpatch

[GoogleCodeExporter]

I have tried the patch, but the issue persists.
No, I haven't used UpdatePointer in my config.

Original comment by k.kosciu...@gmail.com on 15 Aug 2008 at 10:51

[GoogleCodeExporter]

This bug isn't related to focusFollowsMouse configuration setting. I have 
tested that
setting this option to False and changing focus with keyboard also triggers the 
bug. 

Original comment by k.kosciu...@gmail.com on 9 Sep 2008 at 10:04

[GoogleCodeExporter]

I have some further findings, obtained by logging Events using EventHook.

After switching focus from floating "Open File" dialog window to main OO 
window, I
recorded a repeating sequence of events (fields abbreviated/omitted):

PropertyEvent {send_event = False, window = ...75, atom = 141, time = ...31,
propstate = 0}
PropertyEvent {send_event = False, window = ...07, atom = 141, time = ...31,
propstate = 0}
PropertyEvent {send_event = False, window = ...75, atom = 141, time = ...42,
propstate = 0}
PropertyEvent {send_event = False, window = ...07, atom = 141, time = ...42,
propstate = 0}

xlsatoms shows that atom 141 == WM_STATE, and Xlib programming manual says:
"According to ICCCM adopted as of Release 4, the window manager sets this 
property on
top level windows".

I guess that OO spins idle trying to identify the top-level window, without 
being
prepared for failure... Arguably this is a bug in OO rather than in xmonad, but
probably proper handling of WM_STATE on xmonad's side wouldn't hurt. 

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

[GoogleCodeExporter]

I have observed a very similar effect, and the cause was use of 
XMonad.Actions.Warp
with recent xmonad (0.8 for sure, maybe even 0.7?). Changing to use
XMonad.Action.UpdateMouse fixed the problem for me, or so it seems.

Original comment by lucia.cu...@gmail.com on 25 Nov 2008 at 6:34

[GoogleCodeExporter]

I'm experiencing exactly this issue with todays darcs checkout. As I use
X.A.UpdatePointer, I do have the opportunity to not move the mouse out of the 
window,
however, I often forget about this (it's my first day of focusFollowsMouse) and 
have
to kill ooffice from console.

Original comment by liskni...@gmail.com on 25 Oct 2009 at 10:38

[GoogleCodeExporter]

I am not able to reproduce this with or without UpdatePointer using gentoo
openoffice-bin-3.1.1. I have seen it in the past with oo 3.0.1 but not recently 
even
though still on that version on ubuntu jaunty box. I am using EWMH support and
updatePointer Relative regularly on both these machines, fwiw.

Original comment by wirtwo...@gmail.com on 25 Oct 2009 at 11:08

[GoogleCodeExporter]

I was able to fix it by not exporting SAL_USE_VCLPLUGIN=kde (or gtk). That 
should be
equivalent to SAL_USE_VCLPLUGIN=gen for people whose ooo detects gnome/gtk. 
While
trying to reproduce, did you use the generic look or kde/gtk?

Original comment by liskni...@gmail.com on 25 Oct 2009 at 11:36

[GoogleCodeExporter]

Yes, indeed, this setting makes a big difference.

SAL_USE_VCLPLUGIN was not set in any environment on any of my
machines. Exporting SAL_USE_VCLPLUGIN=gtk starts a fight between
OO and xmonad updatePointer for control of the mouse pointer
whenever new dialogs or toolbars get created.

SAL_USE_VCLPLUGIN=kde seems to work fine with updatePointer,
as does gen or leaving it unset. However, on these machines, as
far as kde support is concerned I've only installed the minimum
needed to run kdiff3, so most of kde is likely missing, skewing
the results.

Using gtk works fine so far with updatePointer removed from
logHook. Will try appending it to my navigation key actions
instead. That should reduce or eliminate conflicts while still
allowing gtk themed OO plus pointer updates.

Original comment by wirtwo...@gmail.com on 26 Oct 2009 at 7:45

[GoogleCodeExporter]

Same issue here, on Gentoo with xmonad-0.9 and openoffice-bin-3.2.0. Adding 
'export SAL_USE_VCLPLUGIN=gen' to ~/.xsession worked a treat!

Original comment by wapcaplet88 on 21 Jul 2010 at 6:22

[GoogleCodeExporter]

Is this really an Xmonad bug or should this be reported on LibreOffice bug 
tracker (or OOo one) ?

Original comment by girard.cedric on 25 Oct 2010 at 3:57

[GoogleCodeExporter]

girard.cedric> Nope, this is _not_ a Xmonad issue but the stupid OpenOffice.org 
behaviour when it tries supply improper desktop handling of some common used 
window managers. OO has same or similar problems with other tiling window 
managers like Stumpwm or wmii.

What would be next OO's next feature ? Filesystem defragmentation or procesess 
scheduler ?!

Original comment by dunric...@gmail.com on 12 Jan 2011 at 1:58

[GoogleCodeExporter]

getting the same behaviour with Pandora client after the recent Adobe Air 
update. doIgnore "helps".

Original comment by konstant...@gmail.com on 15 Apr 2011 at 3:37

[GoogleCodeExporter]

Using XMonad.Hooks.EwmhDesktops fixes this issue for me (setup according to 
http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-EwmhDesktops.html). 
I'm running xmonad 0.9.2 and libreoffice 3.4.3.

Original comment by mesz...@gmail.com on 2 Oct 2011 at 10:00

[GoogleCodeExporter]

I can confirm like http://code.google.com/p/xmonad/issues/detail?id=200#c15 
that with xmonad 0.10 and libreoffice 3.5.4.2 enabling emwh helps eliminate the 
floating dialog flicker loop in LibreOffice. I used to get a 10 - 15 second 
loop, now it's just a flicker or two, and I can keep working. 

Original comment by alex.hen...@gmail.com on 10 Nov 2012 at 7:12

[GoogleCodeExporter]

Could someone try setting borderWidth to 0?  We just had someone see something 
similar from Steam for Linux and the problem was revealed by xscope to be that 
their window placement code didn't support server-side window borders, so it 
got confused about where the dialog was relative to the root window and tried 
to "fix" it by closing and reopening it.

Original comment by allber...@gmail.com on 10 Nov 2012 at 7:21

[GoogleCodeExporter]

tried it with borderWidth = 0 --> Problem solved! However, i need some form of 
border...so this is not very handy.

Original comment by ptr...@gmail.com on 14 Feb 2013 at 2:44

[GoogleCodeExporter]

Right, I wasn't suggesting that as a solution, just as a way to try to diagnose 
what's going on.  Unfortunately, this means it's likely a bug in LibreOffice.  
Although, does using EwmhDesktops help as specified by others here?

Alternately, as an ugly workaround it might be possible to identify just the 
LibreOffice dialog windows in the ManageHook and only force those windows' 
borders to 0.  Something like (note, I don't have any idea if this will 
actually match LibreOffice dialogs, it's just an example)

    className =? "LibreOffice" <&&> stringProperty "WM_WINDOW_ROLE" =? "dialog" -->
      ask >>= \w -> liftX (withDisplay $ \d -> setWindowBorder d w 0) <+> idHook

Original comment by allber...@gmail.com on 14 Feb 2013 at 3:14

[GoogleCodeExporter]

The provided code does not work, 'setWindowBorder :: Display -> Window -> Pixel 
-> IO ()' , not -> X (Endo StackSet). Even mixing in 'io' to convert to 'X ()' 
doesn't fully fix it.

For example this doesn't work:

    -- really is: 'doRemoveBorders :: Query ()'
    doRemoveBorders :: Query (Endo WindowSet)
    doRemoveBorders = ask >>= \w -> liftX . withDisplay $ \d -> io $ setWindowBorder d w 0

That said, using ewmh as recommended appears to fix it entirely.

Original comment by cpscha...@gmail.com on 1 Mar 2013 at 12:37

[GoogleCodeExporter]

I can also confirm that the workaround posted in 
http://code.google.com/p/xmonad/issues/detail?id=200#c15 helps. It does not 
prevent flicker, but prevents the entire system from becoming unusable and 
unresponsive.

LibreOffice is not the only program that this is an issue with. I encountered 
it both with LibreOffice dialog boxes, and with dialog boxes from a VLSI CAD 
software suite by a company called Cadence.

Original comment by collinst...@gmail.com on 24 Oct 2013 at 8:12

[GoogleCodeExporter]

I've seen very similar behavior using the emacs 'ediff' diff/merge tool, if I 
try to make the ediff control window a floating window.
xmonad 0.11
emacs 24.3.1
On Arch linux.  I'll try some of the suggestions...

Original comment by dan.krejsa@gmail.com on 21 Feb 2014 at 6:03

[GoogleCodeExporter]

OK, enabling XMonad.Hooks.EwmhDesktops does NOT appear to affect the case with 
emacs ediff for me.

Original comment by dan.krejsa@gmail.com on 21 Feb 2014 at 6:22

[GoogleCodeExporter]

No, it won't affect ediff, that's one of many frame-related bugs in emacs.

Emacs likes to think it gets to decide things like focus (this hasn't been true 
or legal since X11R4), so when the window manager sets the focus emacs decides 
it wants another frame to have focus instead and moves it. Most window managers 
don't pay attention to emacs forcibly setting focus, xmonad is being strict 
about ICCCM/EWMH and switching focus back. It's the equivalent of Chrome and 
Firefox switching focus around, except they use EWMH to tell the window manager 
to do it instead of just slamming it themselves and if you hack EWMH to ignore 
the focus change message you can override it.

(I have managed to provoke all kinds of weird behavior from emacs' frame 
support. Speedbar is another good way to do it; if you try to capture it in an 
IM layout, it will constantly escape the layout. I gave up, as the emacs folks 
don't appear to have any intention of following ICCCM or EWMH.)

Original comment by allber...@gmail.com on 21 Feb 2014 at 2:45

[GoogleCodeExporter]

Thanks alber..., I'll work around the emacs issue.
Not being knowlegeable about X topics I looked up the Wikipedia article on 
ICCCM and was amused by a couple of the references ;-)

Original comment by dan.krejsa@gmail.com on 21 Feb 2014 at 4:40

[GoogleCodeExporter]

Hello, I'd like to add my comment on this bug because it also affects me.

It usually happens with firefox but it can also happens with urxvt.
I have tried the EWMH solution without much success. Since firefox is launched 
on a workspace that is configured with noBorders I did not try the 0-border 
size solution.

The bug manifest itself by spinning between two windows, I break this loop by 
pressing again the key combination to switch to another window. Then in that 
case sometimes the focus is on the displayed window (I am using a Tabbed 
Simplest layout) sometimes on the other window. One way I have found to reset 
everything to the normal state is to create a new firefox window and then 
closing it.

I am using xmonad 0.11 on a debian sid box (all packages comes from the 
standard repository). I have attached my xmonad.hs configuration …

Let me know if I can be of any help.

Original comment by nicolas....@b2ck.com on 5 Mar 2014 at 1:50

Attachments:

• xmonad.hs