[PATCH] user32: Try harder to find a target for mouse messages (resend)

Huw Davies huw at codeweavers.com
Fri Feb 2 02:33:06 CST 2018


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 at codeweavers.com>
> Signed-off-by: Fabian Maurer <dark.shadow4 at 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.



More information about the wine-devel mailing list