https://bugs.winehq.org/show_bug.cgi?id=48121
--- Comment #30 from Jan Braun janbraun@gmx.net --- I'm affected by this bug as well, and setting UseTakeFocus=N works around it. This is very surprising, because my WM (ratpoison) does not support WM_TAKE_FOCUS at all, and I think it indicates a bug in wine:
The way I read https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7 , the WM_TAKE_FOCUS machinery is merely an additional way the WM may use to assign focus to wine. Setting the WM_PROTOCOLS property indicates that wine is prepared (and prefers) to receieve the WM_TAKE_FOCUS ClientMessage instead of being focused directly. It must still be prepared to receive the focus directly. (If that's not obvious, consider the "A client could receive WM_TAKE_FOCUS when opening from an icon..." sentence, which would be meaningless if the client was supposed to only ever get focused via WM_TAKE_FOCUS.) Thus UseTakeFocus=Y should have only 2 effects: setting the atom in WM_PROTOCOLS (and possibly the input field in WM_HINTS), and handling the ClientMessage. If the WM doesn't support WM_TAKE_FOCUS (nor WM_HINTS), the former is inconsequential, and the latter will never be received. Therefore, the value of UseTakeFocus should not be able to change observable behaviour.
However, in X11DRV_FocusIn(), wine *does* things differently depending on the value of use_take_focus (winex11.drv/event.c:802). That's as far as I got, hopefully somebody with more familiarity with the wine code base can figure out what wine is trying to achieve with that distinction, and what the proper handling should be.