[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