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

[Fabian Maurer]

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(a)codeweavers.com>
Signed-off-by: Fabian Maurer <dark.shadow4(a)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 ))
diff --git a/dlls/user32/tests/input.c b/dlls/user32/tests/input.c
index e52f7d215f..437e70cfb6 100644
--- a/dlls/user32/tests/input.c
+++ b/dlls/user32/tests/input.c
@@ -2029,8 +2029,8 @@ static void test_Input_mouse(void)
         }
     }
     ok(hittest_no && hittest_no<50, "expected WM_NCHITTEST message\n");
-    todo_wine ok(got_button_down, "expected WM_LBUTTONDOWN message\n");
-    todo_wine ok(got_button_up, "expected WM_LBUTTONUP message\n");
+    ok(got_button_down, "expected WM_LBUTTONDOWN message\n");
+    ok(got_button_up, "expected WM_LBUTTONUP message\n");
     DestroyWindow(static_win);
 
     /* click on HTTRANSPARENT top-level window that belongs to other thread */
-- 
2.16.1

[Huw Davies]

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

[Alexandre Julliard]

Huw Davies <huw(a)codeweavers.com> writes:
> 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.

Note that it may still be possible to implement heuristics that would be
reasonably safe and may help at least in some cases. For instance, it
may be acceptable to check only the window directly behind the
HTTRANSPARENT one, and accept it if it belongs to the same process and
is the owner of the transparent popup.

-- 
Alexandre Julliard
julliard(a)winehq.org