[PATCH] winex11.drv: Wait for XGrabPointer to succeed on FocusIn events.

[Kimball Thurston]

Sorry, randomly saw this, and don't know the full context, so sorry if this
is a rehash of what you've already looked at, or I didn't understand what
you're trying to fix.

But shouldn't you be doing the normal focus lost / gain notification, but
instead paying attention to the EnterNotify for this condition? When the WM
ungrabs the pointer, you won't necessarily receive a Focus In, but rather
you should always receive an EnterNotify, and I believe it should have mode
= NotifyUngrab and a detail of NotifyAncestor. In that condition, you could
send the WM_ACTIVATE at that time and not try to track the focus gained /
lost, which you may not get? For example, playing w/ xev under the awesome
WM, when I use the hotkey + mouse to move a window, the window doesn't lose
/ gain focus while that happens, but it does receive the EnterNotify with
the above conditions when the WM finishes the move.

Kimball



On Fri, Sep 20, 2019 at 8:11 PM Rémi Bernon <rbernon at codeweavers.com> wrote:

> On 9/19/19 1:09 PM, Alexander Julliard wrote:
> > Rémi Bernon <rbernon at codeweavers.com> writes:
> >
> >> Because on X11 we cannot accurately reproduce the proper non-client
> >> messages sequence when using decorated windows, applications sometimes
> >> assume it is safe to call ClipCursor with a rectangle that matches the
> >> current window position as soon as they receive a WM_ACTIVATE message.
> >> When the WM finishes moving the window, and since commit
> >> 92177b0b161e91f1d609615d89d8e3199feea33f we would retry to clip the
> >> cursor with an incorrect rectangle.
> >>
> >> Before the WM starts moving a window, an active pointer grab is usually
> >> initiated and we can use the result of XGrabPointer to decide whether
> >> the window is really focused or if we should wait until the WM has
> >> finished.
> >>
> >> This adds a pseudo modal loop that waits for XGrabPointer to succeed -
> >> without any confine window to avoid spurious cursor movements - before
> >> notifying the applications of FocusIn events.
> >
> > I don't think that's not a good idea. We used to have waits at various
> > points to try to synchronize with the WM, but in the end it causes more
> > trouble than it's worth. There's always some WM that doesn't follow the
> > expected sequence, and then you get long timeouts and deadlocks. You
> > need to find a way to make this work asynchronously.
> >
>
>  From my investigation it looks to me so far that calling XGrabPointer
> is the most "reliable" way - and so far the only way - to tell if a
> window manager is manipulating a window or not, and if there's some WM
> out there that do not grab the cursor while moving their window... well
> it's going to be the same as the current situation where applications
> assume they can freely control the cursor.
>
> Then there could theoretically be some environments where it is not
> possible to ever grab the pointer, in which case I don't see any
> practical solution to this.
>
> If it is better, it could be possible to delay the processing of FocusIn
> events until the grab succeeds. Retrying on every new event instead of
> actively waiting for it. Of course, if it is not possible to grab the
> pointer at all, then we're screwed as well.
> --
> Rémi Bernon <rbernon at codeweavers.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190920/dd8f93a7/attachment.htm>