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@codeweavers.com wrote:
On 9/19/19 1:09 PM, Alexander Julliard wrote:
Rémi Bernon rbernon@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@codeweavers.com