What steps will reproduce the problem? 1. Have a dual-head setup with a tabbed layout on one screen. 2. Move the mouse pointer into the tabbed screen. 3. Use the keyboard to move focus to the non-tabbed screen. 4. Click a tab with the mouse.

What is the expected output? What do you see instead? I expect the tab’s window to be focused. Instead, nothing happens.

What version of the product are you using? On what operating system? xmonad from darcs.

Please provide any additional information below.

If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. Component-Contrib

I've just pushed a patch to the core, can you confirm that this issue is resolved?

Comment deleted

Now it’s even more broken for me… When I click on a tab, sometimes the window changes, sometimes not. Even if the window does change, though, the tab I clicked does not become hilighted until I move the mouse into the window. And sometimes when I click a tab and move my mouse to the other screen, the focus switches back to the window that had focus before I clicked the tab.

Spencer I'd say your fix is broken. You should figure out which screen the button event is in, bring that screen into focus (if it's not) and then sendMessage as before. (Sorry for the duplicate bug report, by the way, I hadn't realized that this bug report included mention of the additional brokenness in tabbed, and assumed it was a new issue.)

Note that issue #113 describes another symptom of this issue.

The fix is correct -- xmonad should not handle button messages as such a special case.

The underlying issue is that both 'broadcastMessage' and a layout's message handler may need to edit the windowset. This tends to work alright in some cases, but strange things happen when workspace or screen focus changes. We need to provide some way for layouts to queue these state changes that should be applied after the message handler returns. Additionally, we should find some way to statically prevent these unsafe calls to 'windows' in layouts and message handlers.

No, I would say that a mouse event is inherently spatial, and sending this event to layouts that aren't in the right location is wrong. Fixing this would also fix issue

40.

Comment deleted

Comment deleted

Comment deleted

I'm adding the last version of my fix proposal here too.

more info here: http://www.haskell.org/pipermail/xmonad/2008-February/004860.html

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

Final version of this. Can David and other interested parties confirm this is resolves the issue?

The patch fixes it for me.

Applied.