wrong focus after search

[GoogleCodeExporter]

Roughly sometimes when trying to bring up a window an a different desktop, the 
focus insists on following the mouse, rather than going to the window that was 
selected. 

What steps will reproduce the problem?
1. Bring up two windows on view 1. Position cursor over the bottom one. 
2. alt M to view 2. 
3. search (altS ?) and select the first window. 

What is the expected output? What do you see instead?
Expect: The view changes to 1 with the focus in the second window. 
Instead the focus is on the window with the cursor. 
This is more perplexing, because focus is stable when switching (i.e. going 
back to view 1 from 2, the last focused window is still focused regardless of 
where the cursor is.) 
Note also, which window last had focus is irrelevant, the focus is consistently 
following the mouse.

Original issue reported on code.google.com by wmd...@gmail.com on 8 Mar 2011 at 10:30

[GoogleCodeExporter]

The problem I'm facing with the search function is that it's only showing me 
the first window in view 1 regardless of the number of views I have, or how 
many windows are within each view. 

Regardless, it seems like the reason this only happens sometimes is because the 
mouse is moving slightly. Whenever the mouse moves it steals focus. Possibly 
the issue is that the mouse CAN steal focus and not that the focus itself is an 
issue. 

Perhaps forcing the action of a mouse click for focus stealing would be the 
appropriate answer? -bkl

Original comment by benjamin...@gmail.com on 25 Mar 2011 at 9:11

[GoogleCodeExporter]

Okay I see now why I was having difficulty with the window names. Just windows 
naming themselves in general. 300 character names that get pushed off screen, 
check.

Still the mousclick to focus seems the applicable solution to this.

Original comment by benjamin...@gmail.com on 25 Mar 2011 at 9:29

[GoogleCodeExporter]

rev 194 fixes this. 
It seems that what was happening was that goto_view() was being called if the 
window was on another view. But goto_view() actually maps the windows of the 
new view. This in turn generated an enterNotify for whatever window was mapped 
under the cursor. When search_wins() returned to the event loop the 
enterNotifyEvent was waiting, but since layout() hadn't actually been called 
and last_redraw hand't been updated (the mapping was done in goto_veiw()), the 
time check (comparing last_redraw to the current time) didn't tell us to ignore 
it, so it got processed, and the focus got changed. 

Now what I still can't understand is why this issue wasn't coming up every time 
we tried to change views. The same hole in my logic would seem to apply. 

Either way, it seems to be fixed now. 

Original comment by wmd...@gmail.com on 30 Mar 2011 at 6:03

• Changed state: Fixed