If the current thread isn't the foreground thread. Otherwise we may
clip the cursor in the wrong thread, that isn't expecting mouse messages
or may not be checking its messages.
Red Faction has some race condition where this can happen for instance,
with clip_fullscreen_window called from X11DRV_DisplayDevices_Update
callback in a background thread. This thread starts clipping the cursor,
and the foreground thread isn't receiving MotionNotify events anymore.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The message was sent to two different types of windows, with a different
semantic. We can now add parameters to the request without changing the
notify parameters semantics.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The messages are in flight, the state will be updated eventually in
the order they are received by the desktop thread, we shouldn't have
to wait. If the clipping window gets overwritten, it will also receive
a message from the desktop thread, which is sent asynchronously already.
Call of Duty: WWII calls ClipCursor in a loop on startup while the
foreground thread is stalled and the messages sometimes pile up. The
recursive message processing that SendMessageW induces can then cause
stack overflows.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49643
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
X11 Mouse buttons 6 and 7 were set to translate into browser
back/forward button events. However, this is based on an old convention
where buttons 6 and 7 could either mean horizontal scroll or browser
back/forward. Nowadays, 6 and 7 solely mean horizontal scroll, 8 and 9
being used for back/forward. In addition, the wide adoption of
two-finger two-dimensional scrolling on laptop trackpads since this code
was written has meant that back/forward events may be generated
unintentionally, which can be very disruptive when using tools such as
web browsers.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49142
Signed-off-by: Murray Colpman <muzer@tim32.org>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes a regression introduced by 74efb3e872,
which caused some random pointer warping on a setup with multiple "workspaces"
when switching between them and a full screen game that warped the mouse.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When the same thread repeatedly calls ClipCursor, a message window is
created for every call, then stored in x11drv_thread_data->clip_hwnd.
The WM_X11DRV_CLIP_CURSOR notification is then sent to the desktop
window, then to the previous clipping thread in order for it to destroy
its clip_hwnd. But as the clipping thread is the same, and because
x11drv_thread_data->clip_hwnd has been overwritten, it does not satisfy
the "hwnd == data->clip_hwnd" condition and the window leaked.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
XWarpPointer will always succeed, regardless of grabs, so if the pointer
is already grabbed, by some other application, we should not ask to warp
it.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As we ignore these NotifyGrab / NotifyUngrab w.r.t focus decisions,
some applications are unaware of mouse grabs being lost and sometimes
cursor clipping is lost. We have to keep the last clip rectangle and
restore it when grab is released.
This has been squashed with the foreground window check from
Zhiyi Zhang <zzhang@codeweavers.com> to fix an issue that happens when
switching from a fullscreen window - because there's some additional
focus events involved - but in general, if the window that is getting
focus cannot be activated:
When FocusIn/NotifyWhileGrabbed is received, SetForegroundWindow is not
called if the window cannot be activated. When the FocusIn/NotifyUngrab
event arrives for the same window, we have to check the foreground
window before restoring cursor clipping rectangle.
For reference, the event sequence when pressing Alt-Tab - for WMs that
grab the keyboard - is the following:
1. FocusOut/NotifyGrab, when WM grabs the keyboard.
2. FocusOut/NotifyWhileGrabbed, while WM switches windows, this calls
SetForegroundWindow(GetDesktopWindow()).
The event sequence for normal windows ends here, but for fullscreen
windows, there may be these additional events:
3. FocusIn/NotifyWhileGrabbed, which may not change Wine foreground
window if it cannot be activated.
4. FocusIn/NotifyUnGrab, when WM releases the keyboard while switching
windows, this is ignored but it should not retry to grab the cursor,
because window is not foreground.
5. FocusOut/NotifyNormal, when WM finishes switching the windows.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When the window manager has taken a keyboard grab, it may be going to
move the window itself, so the application should not move the cursor
at the same time.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of selecting for XI2 events for every slave device individually,
do it for XIAllDevices, and store the current device's relative X/Y
valuators so they can be quickly looked up in the XI_RawMotion events
received.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Use XI2's client pointer, it will be the master pointer affected by X
core calls, and even if it doesn't currently have relative X/Y
capabilities, it will gain those as soon as a slave device with such
capabilities is used.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
After processing several X events, X11DRV_MsgWaitForMultipleObjects always
tells us that a new message is available. This is not true for some cases.
For instance, when we call DestroyWindow, the X queues DestroyEvent. Then,
X11DRV_MsgWaitForMultipleObjects handles the event only; none is posted or
sent as hwnd for destroyed window is unavailable. However, the function
states "new message is available" by returning count - 1 value.
This is an issue for CoWaitForMultipleHandles because it expects a new
message in the queue and consumes the message.
Signed-off-by: Akihiro Sagawa <sagawa.aki@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't want to clip in the desktop process, but we still need it to call
ungrab_clipping_window() if the process that was previously clipping didn't.
This can happen for example when fullscreen clipping is enabled, but the
corresponding window isn't explicitly destroyed before process exit.
Rémi Bernon