The if condition here came from 47c54c4ae7,
which is to detect full screen window.
However, according to tests in previous commit, there is possibility
that a window without setting WS_CAPTION is not full screen, for example,
main window of Tencent WeChat. And windows like this can also be maximized
or restored. So that we can not treat WS_CAPTION as our full screen condition.
This fixes maximizing Tencent WeChat by dragging it to screen edge.
Signed-off-by: Ziqing Hui <zhui@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It doesn't, and we then lookup HWND from an invalid Window value.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Commit 71d35d8940 broke the way
WM_TAKE_FOCUS protocol is implemented: WM_MOUSEACTIVATE now replies
MA_NOACTIVATE by default when using HTCAPTION.
We use the WM_MOUSEACTIVATE -although Windows does not- regardless of
the way focus is changed to check whether a window wants focus, and
Windows sometimes changes focus regardless of the message reply.
Steam and the Wine system tray are affected for instance.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
These events are received on mutter, when moving undecorated managed
windows, although Wine never grabs the keyboard itself.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This flag should only indicate a successful call to XGrabPointer. If not
then we could assume we have ownership of the pointer when we don't.
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>
Several window managers are sending FocusOut with NotifyGrab mode
then FocusOut with NotifyWhileGrabbed mode when a window focus is lost,
as a consequence of grabbing the keyboard input before changing window
focus.
This is the case during alt-tab, but keyboard can also be grabbed when
bringing activity view or clicking on the title bar. In this cases
NotifyWhileGrabbed events aren't sent until the window really loses
foreground.
In the same manner, when focus is restored, they usually send FocusIn
with NotifyWhileGrabbed mode followed by FocusIn with NotifyUngrab mode
when the keyboard grab is released.
When bringing activity view back and forth, or clicking on the title
bar, only NotifyUngrab event will be sent.
In order to be consistent across WM and to help simplifying focus
handling, just ignore focus events related to keyboard grabs.
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>
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>
In some cases, WM's will modify the _NET_WM_STATE of our own windows.
Most notably, this can happen when the WM maximizes our window, but
mutter has been known to alter the fullscreen state as well. If we
want to reconfigure our window later, we'll probably have to remove
these states, which means we need to remember that they were set.
Ziqing Hui