Comment #14 on issue 200 by konstant...@gmail.com: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 getting the same behaviour with Pandora client after the recent Adobe Air update. doIgnore "helps".

Comment #16 on issue 200 by alex.hen...@gmail.com: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 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.

Comment #18 on issue 200 by ptr...@gmail.com: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 tried it with borderWidth = 0 --> Problem solved! However, i need some form of border...so this is not very handy. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

Comment #20 on issue 200 by cpscha...@gmail.com: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 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. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

Comment #22 on issue 200 by dan.krejsa@gmail.com: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 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... -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

Comment #24 on issue 200 by allber...@gmail.com: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 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.) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

Comment #26 on issue 200 by nicolas....@b2ck.com: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 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. Attachments: xmonad.hs 3.8 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings