On Thu, Feb 01, 2018 at 11:21:33PM +0100, Fabian Maurer wrote:
Fixes bug 12007 and bug 44012. This is an old patch from staging. It seems to have been rejected back then, but I couldn't find any info on why.
From: Dmitry Timoshkov dmitry@codeweavers.com Signed-off-by: Fabian Maurer dark.shadow4@web.de
dlls/user32/message.c | 2 +- dlls/user32/tests/input.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/user32/message.c b/dlls/user32/message.c index 172d6593f6..46e39c8bcb 100644 --- a/dlls/user32/message.c +++ b/dlls/user32/message.c @@ -2502,7 +2502,7 @@ static BOOL process_mouse_message( MSG *msg, UINT hw_id, ULONG_PTR extra_info, H } else {
msg->hwnd = WINPOS_WindowFromPoint( msg->hwnd, msg->pt, &hittest );
msg->hwnd = WINPOS_WindowFromPoint( 0, msg->pt, &hittest );}
if (!msg->hwnd || !WIN_IsCurrentThread( msg->hwnd ))
I sent in the same patch a few days ago: https://source.winehq.org/patches/data/140856 (although at the time I didn't realise it existed in staging). See AJ's reply: https://source.winehq.org/patches/data/140965
The problem is that there could be a non-Wine window in between the original msg->hwnd and the window which WindowFromPoint finds. In this case the user would expect the mouse event to be handled by the non-Wine window, not the Wine window behind it.
To fix this we'd need support from the native windowing system.
See also: https://bugs.winehq.org/show_bug.cgi?id=8914 which describes the problem and is closed WONTFIX (although CANTFIX would be better).
Huw.