[Bug 19874] New: If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

Summary: If mouse focus lost then keyboard focus never
                    recovered (Team Fortress 2)
           Product: Wine
           Version: 1.1.28
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

When the mouse unsticks from my game window (old old wine bug, can't find the
reference right now) there's the risk of clicking outside the game window and
thus losing focus.  Unfortunately when this happens I am unable to return the
keyboard focus to the game: I end up in the odd state where mouse movements
still go to the game, but keyboard input goes to other windows.  The only
remedy seems to be to kill with `wineserver -k` and restart.

I'm running Team Fortress 2 in a virtual desktop, but on a dual monitor setup
(so the mouse has room to go outside the game window).

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #1 from Jeff Zaroyko   2009-08-28 15:32:15 ---
sounds like a regression... you could have run a regression test.
http://wiki.winehq.org/RegressionTesting

Could be related or a duplicate of bug 19822, can you try reverting the two
patches mentioned to see if it works again?

git revert 12d1ff8ef6c34533a20008f4cfeb73ee4c601a5d
git revert e3720c2810dda3895d6734c55117b0a355223b1a

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #2 from Michael Abbott   2009-08-28 16:43:43 ---
(In reply to comment #1)
> sounds like a regression... you could have run a regression test.

Hmm.  Don't know if it's ever worked properly, so I don't have a good starting
point (unless the reverts below work).

Would be one hell of a long regression test (getting into the game in TF2 takes
around ten minutes from the command prompt!)  Even in the best circumstances a
wine regression can take the best part of a day.
> Could be related or a duplicate of bug 19822, can you try reverting the two
> patches mentioned to see if it works again?
>
> git revert 12d1ff8ef6c34533a20008f4cfeb73ee4c601a5d
> git revert e3720c2810dda3895d6734c55117b0a355223b1a

Looks interesting.  I'll try that, will probably have to wait a week or so
though.

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #3 from Vitaliy Margolen   2009-08-28 18:57:20 ---
Yes, it's a duplicate.

*** This bug has been marked as a duplicate of bug 19822 ***

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #4 from Vitaliy Margolen   2009-08-28 18:58:41 ---
Closing

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #5 from Michael Abbott   2009-09-03 14:32:44 ---
(In reply to comment #1)
> Could be related or a duplicate of bug 19822, can you try reverting the two
> patches mentioned to see if it works again?
>
> git revert 12d1ff8ef6c34533a20008f4cfeb73ee4c601a5d
> git revert e3720c2810dda3895d6734c55117b0a355223b1a

Yes, can confirm that these reverts remove the problem.

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

Michael Abbott  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |UNCONFIRMED
         Resolution|DUPLICATE                   |

--- Comment #6 from Michael Abbott   2009-09-04 02:00:57 ---
Bug 19822 has been closed as fixed, so alas I have to reopen this.  Clicking on
TF2 full screen doesn't give it back focus.

To reproduce (window manager in this case is fluxbox, I'll try again with xfce
and report back):

1. Run up Steam (oops, the browser is a bit busted now, separate bug report).
2. Run up Team Fortress 2
3. Bring up the server browser
4. Click in the tags window and type to verify the window has keyboard focus
5. Click away in another window, outside of wine
6. Click back in the server window.  Notice that the window manager sees no
change of focus!
7. Type to verify that the keyboard focus is still outside wine.

However, Alt-Tab style focus changing now works, so the problem is much less
severe than before.

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #7 from Michael Abbott   2009-09-04 02:21:52 ---
(In reply to comment #6)
> I'll try again with xfce
>
> However, Alt-Tab style focus changing now works, so the problem is much less
> severe than before.

Well, with xfce, Alt-Tab focus changing does not return focus to the
application, so the original bug report stands as first described.

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #8 from Vitaliy Margolen   2009-10-05 20:20:37 ---
*** Bug 20272 has been marked as a duplicate of this bug. ***

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #9 from Michael Abbott   2009-10-06 05:39:51 ---
(In reply to comment #8)
> *** Bug 20272 has been marked as a duplicate of this bug. ***

Then it's probably worth copying over the regression noted in bug 20272:

A regression test between 1.1.27 and 1.1.28 results in the following bad
commit:
> e3720c2810dda3895d6734c55117b0a355223b1a is first bad commit
> commit e3720c2810dda3895d6734c55117b0a355223b1a
> Author: Alexandre Julliard 
> Date:   Thu Aug 13 18:18:22 2009 +0200
> winex11: Use the Globally Active focus model with take focus.
>
> :040000 040000 d1fb1709094e60472024b78cf46f7e4c8a451b47 d7b2f829e9cd01101173cc4e65c4e6ff0bb7c6c0 M	dlls

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |regression
          Component|-unknown                    |winex11.drv

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

Wylda  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #10 from Wylda   2009-10-06 12:03:55 ---
*** This bug has been confirmed by popular vote. ***

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #11 from Adrian   2009-10-06 14:24:52 ---
Created an attachment (id=23958)
 --> (http://bugs.winehq.org/attachment.cgi?id=23958)
Bisect Messages

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

Adrian  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #12 from Adrian   2009-10-06 14:30:03 ---
Same Error. Keyboard looses focus if you 
-switch workspace
-be on an other display(twinview/xinerama) at loading game
-click on an other Display at playing

sry for doubleposting.

Terminal says:

e3720c2810dda3895d6734c55117b0a355223b1a is first bad commit

Long Version in Bisect Messages File

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #13 from Adrian   2009-10-06 14:33:29 ---
I should go to bed know ... ive forgot to say that its for Counterstrike
Source. I thought that here is the right place cause both are hl2 games.

[Bug 19874] If mouse focus lost then keyboard focus never recovered (Team Fortress 2)

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #14 from Alex   2009-10-06 15:43:11 ---
As far as I can tell, it affects not just Source games, but Wine in general.
The same problem happens in notepad, for example, as well as other games I've
tried.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

Michael Abbott  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|If mouse focus lost then    |If mouse focus lost then
                   |keyboard focus never        |keyboard focus never
                   |recovered (Team Fortress 2) |recovered

--- Comment #15 from Michael Abbott   2009-10-06 16:37:12 ---
Removed "Team Fortress 2" from title in response to general observation that
bug occurs somewhat more widely.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

Don Koch  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #16 from Don Koch   2009-10-08 15:03:57 ---
I found that reverting e3720c2810dda3895d6734c55117b0a355223b1a was sufficient
to fix the issue.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #17 from Adrian   2009-10-08 18:01:56 ---
But maybe you damage something other. I ll wait for info from developer if it's
dangerous to revert it.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

Eric Molitor  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #18 from Eric Molitor   2009-10-11 08:32:37 ---
I think that setting UseTakeFocus to N in the X11 Driver registry is a better
workaround for now than reverting the change. I will test this later today..

[Software\Wine\X11 Driver] "UseTakeFocus"="N"

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #19 from Eric Molitor   2009-10-11 09:14:33 ---
(In reply to comment #18)
> I think that setting UseTakeFocus to N in the X11 Driver registry is a better
> workaround for now than reverting the change. I will test this later today..
>
> [Software\Wine\X11 Driver] "UseTakeFocus"="N"

Setting the registry value does work around the issue without reverting any
changes. I'll try to take a look at the code and see if UseTakeFocus should is
intended to be 'N' by default. For now though there is a workaround that is
less invasive.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #20 from Alex   2009-10-12 12:03:48 ---
(In reply to comment #19)
> (In reply to comment #18)
> > I think that setting UseTakeFocus to N in the X11 Driver registry is a better
> > workaround for now than reverting the change. I will test this later today..
> >
> > [Software\Wine\X11 Driver] "UseTakeFocus"="N"
>
> Setting the registry value does work around the issue without reverting any
> changes. I'll try to take a look at the code and see if UseTakeFocus should is
> intended to be 'N' by default. For now though there is a workaround that is
> less invasive.

I can confirm that this fixes the problem.
Adding a String "UseTakeFocus" and setting it to N in
[HKEY_CURRENT_USER\Softwares\Wine\X11 Driver] reverts the focus behaviour to
that of 1.1.27.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

Vincent Povirk  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #21 from Vincent Povirk   2009-10-18 15:17:30 ---
Can you reproduce this bug using a builtin wine program, such as wine notepad?

If so, what window manager are you using?

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #22 from Alex   2009-10-18 22:23:03 ---
(In reply to comment #21)
> Can you reproduce this bug using a builtin wine program, such as wine notepad?
>
> If so, what window manager are you using?

I'm not sure exactly what you're asking, but I'll try my best.

It can be reproduced in wine notepad. Type in notepad, switch to something
outside of wine (like a firefox window or another text editor), then switch
back. Typing appears in the application outside of wine, but wine still
responds to clicks.

I'm personally using GNOME with compiz - I'm not sure what you're asking when
you say window manager, but desktop environment was the closest I could think
of.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #23 from Vitaliy Margolen   2009-10-18 23:29:35 ---
(In reply to comment #22)
> It can be reproduced in wine notepad.

Works fine here (KDE). So you should report your bug to your distro.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #24 from Michael Abbott   2009-10-19 01:27:10 ---
(In reply to comment #21)
> Can you reproduce this bug using a builtin wine program, such as wine notepad?
>
> If so, what window manager are you using?

This report is with fluxbox as my window manager.

1.  If I return focus to Notepad by clicking then it appears to get the
keyboard focus back.  On the other hand, it doesn't recolour its title bar to
indicate that it has received any notification that focus has come back.

2.  If I run wine with a virtual desktop then I can successfully Alt-Tab to the
wine desktop and notepad gets the keyboard focus (to be precise, the fluxbox
functions :NextWindow and :ClientMenu successfully pass keyboard focus to
wine).  It does start with the Alt key pressed (so a second press of the Alt
key is necessary to release the menu selector for typing to actually work), but
that's probably a fluxbox quirk.

So far so good.

However, the coloured title bar on notepad does *not* update correctly to show
that it has received focus, it remains grey (normally indicating unselected). 
In fact, it doesn't even colour its title bar on startup.

3.  I seem to have
    HKCK/Software/Wine/X11 Driver/Managed == "N"
by default.  In this state running notepad without a virtual desktop makes
notepad invisible to the desktop manager -- very confusing, but presumably
that's the point of this setting; don't know how it got set, though.

So lots of quirks to trip me up (my first draft of this note was that it's
still broken: the sticky Alt and unmanaged windows were puzzles), but at the
moment this is looking good.

I'll repeat the test with XFCE and a live game and report back.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #25 from Austin English   2009-10-19 01:31:44 ---
(In reply to comment #22)
> I'm personally using GNOME with compiz - I'm not sure what you're asking when
> you say window manager, but desktop environment was the closest I could think
> of.

Works fine for me in Gnome without compiz.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #26 from Michael Abbott   2009-10-19 01:59:43 ---
Well.  Now that *is* interesting.  Testing with XFCE here.

1.  Running notepad in a virtual desktop and passing focus by clicking works as
before: keyboard focus is successfully handed over, but the title bar colour
does not update.

*However* ...

2.  Alt-Tab loses the focus!  Wine appears in XFCE's Alt-Tab popup window, but
when I deposit the focus back on wine's virtual desktop the keyboard focus is
lost.

3.  If I run notepad in its own window (unset "Enable virtual desktop") then
Alt-Tab seems to work fine.  Everything below is only applicable to the virtual
desktop, this case seems to work just fine.

(Oh, btw, it seems Managed=="N" was my own deliberate doing, not sure why.)

Playing around a bit with (2) is rather confusing.  Try this and follow along
with me:

1. Run `wine notepad` with a virtual desktop enabled
2. Type in notepad to verify it's got the focus
3. Alt-Tab to another window
3.1 Notice that typing in the new window works
3.2 Notice that the File menu selection on Notepad is depressed (it saw the
Alt)
3.3 Notice that Alt-Tab doesn't work at all (*beep*).  Whoops!
4. Mouse click anywhere once to .1 release the File menu and .2 get Alt-Tab
working again
5. Alt-Tab back to notepad and see that the keyboard is NOT working.

Hmm.  There's a combination of mouse clicks, key presses and Alt-Tabs that
successfully does return focus to notepad, but it's a bit difficult to pin
down.

Oh DAMN IT!!!

The keyboard focus is FOLLOWING THE MOUSE!  Argh.

Let me make something quite clear here: I do NOT have "focus follows mouse" set
on my desktop, so this is clearly part of the bug.  Sigh.  Let's start again.

1. Run `wine notepad` in a virtual desktop.
2.1 Notice that the notepad title bar is grey, no focus
2.2 Notice that typing only goes into notepad when the mouse is over the
notepad window.  Whoops...
3. Alt-Tab to another window ... with the mouse *over* notepad.  Behaviour as
before, need to click somewhere else to get Alt- back.
4. Alt-Tab to another window with the mouse *not* over notepad.  Everything
seems normal -- hmm.
5. Alt-Tab back to notepad.  Does the keyboard work?  Well, where's that mouse
got to?  Oh dear.

Ho ho ho.  Well, looks like I need to re-run the fluxbox test, and I'll also
give Gnome a go.

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #27 from Michael Abbott   2009-10-19 02:05:11 ---
Ok, *exactly* the same behaviour under Gnome as under XFCE: Keyboard focus
follows mouse when using a virtual desktop.

This will probably explain why some people are reporting all is well: try again
with a wine virtual desktop, and check where your mouse is!

Should I change the title of the bug to reflect this new behaviour, or would
that be too confusing?

[Bug 19874] If mouse focus lost then keyboard focus never recovered

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #28 from Michael Abbott   2009-10-19 02:08:26 ---
(In reply to comment #27)
> Ok, *exactly* the same behaviour under Gnome as under XFCE: Keyboard focus
> follows mouse when using a virtual desktop.

And with fluxbox.  So identical behaviour all round, window manager
independent, but peculiar to using a virtual desktop.

[Bug 19874] Keyboard focus follows mouse in virtual desktop

http://bugs.winehq.org/show_bug.cgi?id=19874

Michael Abbott  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|If mouse focus lost then    |Keyboard focus follows
                   |keyboard focus never        |mouse in virtual desktop
                   |recovered                   |

--- Comment #29 from Michael Abbott   2009-10-19 02:30:07 ---
Not sure if this is the right thing to do (old bug title was "If mouse focus
lost then keyboard focus never recovered"), but this bug has somewhat mutated
and I'm not sure I want to open a new report.

[Bug 19874] Keyboard focus follows mouse in virtual desktop

http://bugs.winehq.org/show_bug.cgi?id=19874

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|regression                  |
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #30 from Vitaliy Margolen   2009-10-19 08:24:18 ---
Then you got the same problem as been with Wine for ages.

*** This bug has been marked as a duplicate of bug 9320 ***

[Bug 19874] Keyboard focus follows mouse in virtual desktop

http://bugs.winehq.org/show_bug.cgi?id=19874

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #31 from Vitaliy Margolen   2009-10-19 08:24:29 ---
Closing dup

[Bug 19874] Keyboard focus follows mouse in virtual desktop

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #32 from Vincent Povirk   2009-10-19 10:29:51 ---
Someone should confirm that the issue with notepad is caused by the same patch
and either reopen this bug or file a new one, I think.

That it works correctly in some window managers doesn't make this an invalid
bug. Theoretically, the locally active model makes Wine responsible for setting
the focus to its window when it gets a click in its client area (ref:
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7 ). It may be that some window
managers are focusing Wine windows or sending WM_TAKE_FOCUS requests when they
shouldn't.

[Bug 19874] clicking on a window's client area does not give it keyboard focus

http://bugs.winehq.org/show_bug.cgi?id=19874

Vincent Povirk  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
         Resolution|DUPLICATE                   |
            Summary|Keyboard focus follows      |clicking on a window's
                   |mouse in virtual desktop    |client area does not give
                   |                            |it keyboard focus

--- Comment #33 from Vincent Povirk   2009-10-19 11:56:03 ---
I'm reopening this because there is a real problem reported here, confirmed by
multiple people, that is unrelated to bug 9320. It seems that with some window
managers, for some people, clicking on the client area of a window does not
give it keyboard focus. This is the original problem reported, and it looks to
me like Michael was confused and started talking about the virtual desktop
issue, also changing the bug description.

Please do not discuss virtual desktop focus in this bug. It is a separate and
known issue, already filed as bug 9320.

Here is the simplest way to reproduce the issue as I understand it:
1. Be unlucky. (It seems some people can reproduce it and some cannot. I can't
reproduce it, personally. The window manager may be important here.)
2. Use Wine with default settings. (No virtual desktop, allow the window
manager to control and decorate the windows, and do not set the UseTakeFocus
setting.)
3. Start a program, such as wine notepad.
4. Switch to a different application.
5. Attempt to switch to the wine window by clicking in its client area.
6. Type something. The keyboard events go to the other application's window,
not to Wine.

Is this correct?

[Bug 19874] clicking on a window's client area does not give it keyboard focus

http://bugs.winehq.org/show_bug.cgi?id=19874

--- Comment #34 from Michael Abbott   2009-10-19 12:16:38 ---
(In reply to comment #33)
> I'm reopening this because there is a real problem reported here, confirmed by
> multiple people, that is unrelated to bug 9320. It seems that with some window
> managers, for some people, clicking on the client area of a window does not
> give it keyboard focus. This is the original problem reported, and it looks to
> me like Michael was confused and started talking about the virtual desktop
> issue, also changing the bug description.

Yes, I'm sorry about that.  I was unaware of bug 9320, and I'm unable to
reproduce the bug I originally reported, I guess I'm happy to see this bug
marked as fixed now.
> Please do not discuss virtual desktop focus in this bug. It is a separate and
> known issue, already filed as bug 9320.

Yes, the rename was an error; thank you for reverting it.
> Here is the simplest way to reproduce the issue as I understand it:
> - Be unlucky. (It seems some people can reproduce it and some cannot. I can't
>
> reproduce it, personally. The window manager may be important here.)
> 2. Use Wine with default settings. (No virtual desktop, allow the window
> manager to control and decorate the windows, and do not set the UseTakeFocus
> setting.)
> 3. Start a program, such as wine notepad.
> 4. Switch to a different application.
> 5. Attempt to switch to the wine window by clicking in its client area.
> 6. Type something. The keyboard events go to the other application's window,
> not to Wine.
>
> Is this correct?

Well, that wasn't quite my set up: I run all my programs in an undecorated
virtual desktop.  However, I'm unable to duplicate the problem either in my
original report or following the test sequence you describe, so for me this bug
is fixed.  I've checked Gnome, XFCE and fluxbox.

Shall we leave this open for a little bit, or close it again until somebody
else can reproduce a closely related problem?

[Bug 19874] clicking on a window's client area does not give it keyboard focus

http://bugs.winehq.org/show_bug.cgi?id=19874

Vincent Povirk  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #35 from Vincent Povirk   2009-10-19 12:31:27 ---
Well, since the original reporter can no longer reproduce the bug, and there
was no fix released, I'm resolving this as WORKSFORME.

If you can still reproduce this bug, please reply, and tell me if comment 33 is
an accurate description.

[Bug 19874] clicking on a window's client area does not give it keyboard focus

http://bugs.winehq.org/show_bug.cgi?id=19874

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |DUPLICATE

--- Comment #36 from Vitaliy Margolen   2009-10-19 21:00:09 ---
(In reply to comment #33)
> I'm reopening this because there is a real problem reported here

Right, the problem described in my bug which was opened years ago. Nothing was
done about it and all focus problems in virtual desktop are due to it.

*** This bug has been marked as a duplicate of bug 9320 ***

[Bug 19874] clicking on a window's client area does not give it keyboard focus

http://bugs.winehq.org/show_bug.cgi?id=19874

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #37 from Vitaliy Margolen   2009-10-19 21:00:18 ---
Closing.

[Bug 19874] clicking on a window's client area does not give it keyboard focus

http://bugs.winehq.org/show_bug.cgi?id=19874

Michael Abbott  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|DUPLICATE                   |FIXED

--- Comment #38 from Michael Abbott   2009-10-20 02:16:57 ---
(In reply to comment #36)
> (In reply to comment #33)
> > I'm reopening this because there is a real problem reported here
>
> Right, the problem described in my bug which was opened years ago. Nothing was
> done about it and all focus problems in virtual desktop are due to it.
>
> *** This bug has been marked as a duplicate of bug 9320 ***

For the record, I'd like to point out that this bug, as currently described, is
*not* a duplicate of bug 9320 -- my analysis (comment #26) which resulted in my
renaming to a duplicate of bug 9320 was corrected and reverted in comment #33. 
This confusion is precisely why I opened bug 20416, which unfortunately did not
survive very long!

As far as I can tell the bug I reported has been fixed, which is why my
analysis fell back to the old bug.  I've updated the status accordingly.

[Bug 19874] clicking on a window's client area does not give it keyboard focus

http://bugs.winehq.org/show_bug.cgi?id=19874

Vincent Povirk  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |WORKSFORME

--- Comment #39 from Vincent Povirk   2009-10-20 08:04:49 ---
FIXED implies that a fix was committed to Wine. However, there are no recent
Wine commits that are likely to be a fix, and from your description it sounds
like you have no idea whether a Wine update solved it. Therefore, WORKSFORME is
more appropriate.