Child windows can steal focus with mouse input while in relative mode

[GoaLitiuM]

This is an issue on both X11 and Windows: When the relative mode is enabled in one window, pressing mouse buttons when the hidden cursor is hovered over a child window, can steal the focus and disable relative mode.

On X11 the cursor position is constrained within the window where relative mode is enabled, but the cursor can still hover over any child windows that are overlapping with the parent window, and when clicking any mouse buttons while hovering over the child window, the relative mode is disabled and focus is moved to the child window.

On Windows this is harder to reproduce but still possible just like in X11, but while the cursor position is locked to the center of the window when relative mode is enabled, the same situation can happen if any child window is overlapping the parent window around the center of the window.

[Kontrabant]

This is a problem with always-on-top windows as well. I'm not sure how to address this, as it's the window manager giving focus to the window that's technically under the cursor, even if the cursor is hidden and confined.

Maybe @expikr has some idea for how to deal with this on Windows?

[expikr]

When this happens, is the child window above or below the parent?

If it’s below, that’s a very strange bug indicating the logic is doing something it shouldn’t.

If it’s above, I don’t think it’s solvable without compromising regular window switching UX -- by definition if you click on a window, even if the cursor is invisible, the OS will focus that window.

If you want to prevent this behaviour, you’d need to set the window style so that it does not activate upon click (WS_EX_NOACTIVATE), but that would also mean that you can’t activate them if you alt tabbed elsewhere then want to come back by clicking on them, unless you hook the alt tab event so that when the relative parent comes into focus it sets all child windows with that style, and unset every child windows when parent loses focus.

This would introduce a significant amount of coupling to the already beleaguered RelativeMode state machine so I would advise against that.

As mitigation, individual developers could try to manually set the child windows with that style if desired, I feel like building it into the API as an automatic behaviour is inadvisable.

Or maybe an SDL_SetWindowUnclickable() function that lets you do so manually, as a middle ground.

EDIT: seems there is already an SDL_WINDOW_NOT_FOCUSABLE flag, can you confirm the behaviour when setting this flag on the child?

[GoaLitiuM]

When this happens, is the child window above or below the parent?

It's above the parent window (I don't think child windows can be below their parents?).

As mitigation, individual developers could try to manually set the child windows with that style if desired, I feel like building it into the API as an automatic behaviour is advisable.

I was already considering to not use child windows at all for practical reasons, so that would be a workaround for us.

EDIT: seems there is already an SDL_WINDOW_NOT_FOCUSABLE flag, can you confirm the behaviour when setting this flag on the child?

This seems to work if you try to click the client area of the window, but you can still activate the window if the window title is under the cursor. Hovering over the child window seems to reset the mouse constraints for the window under relative mode, allowing the cursor to escape and interact with desktop or other applications.

[slouken]

When this happens, is the child window above or below the parent?

It's above the parent window (I don't think child windows can be below their parents?).

As mitigation, individual developers could try to manually set the child windows with that style if desired, I feel like building it into the API as an automatic behaviour is advisable.

I was already considering to not use child windows at all for practical reasons, so that would be a workaround for us.

EDIT: seems there is already an SDL_WINDOW_NOT_FOCUSABLE flag, can you confirm the behaviour when setting this flag on the child?

This seems to work if you try to click the client area of the window, but you can still activate the window if the window title is under the cursor. Hovering over the child window seems to reset the mouse constraints for the window under relative mode, allowing the cursor to escape and interact with desktop or other applications.

I don't think we've tested child window interactions with relative mouse mode. Do you have a simple test case we can use to reproduce this?

[expikr]

If you want to prevent this behaviour, you’d need to set the window style so that it does not activate upon click (WS_EX_NOACTIVATE), but that would also mean that you can’t activate them if you alt tabbed elsewhere then want to come back by clicking on them, unless you hook the alt tab event so that when the relative parent comes into focus it sets all child windows with that style, and unset every child windows when parent loses focus.

This would introduce a significant amount of coupling to the already beleaguered RelativeMode state machine so I would advise against that.

I was wrong, looks like there is a simple solution:

https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-mouseactivate#remarks

The parent will receive the message before the child gets activated. So if the parent window decides it's in relative mode its window procedure can simply eat the message without activation.

[slouken]

@GoaLitiuM, can you create a simple test case that mimics what's happening in your app?

[GoaLitiuM]

Here is a simple modification to testmodal:

diff --git a/test/testmodal.c b/test/testmodal.c
index 156d61e21..825b412eb 100644
--- a/test/testmodal.c
+++ b/test/testmodal.c
@@ -25,6 +25,9 @@ int main(int argc, char *argv[])
     int i;
     int exit_code = 0;
 
+    SDL_SetHint(SDL_HINT_MOUSE_RELATIVE_CURSOR_VISIBLE, "1");
+    SDL_SetHint(SDL_HINT_MOUSE_RELATIVE_MODE_CENTER, "1");
+
     /* Initialize test framework */
     state = SDLTest_CommonCreateState(argv, 0);
     if (state == NULL) {
@@ -64,9 +67,6 @@ int main(int argc, char *argv[])
     }
 
     if (SDL_SetWindowParent(w2, w1)) {
-        if (SDL_SetWindowModal(w2, true)) {
-            SDL_SetWindowTitle(w2, "Modal Window");
-        }
     }
 
     while (1) {
@@ -137,6 +137,10 @@ int main(int argc, char *argv[])
                             }
                         }
                     }
+                } else if (e.key.key == SDLK_R) {
+                    SDL_Window* window = SDL_GetWindowFromID(e.key.windowID);
+                    bool relative = SDL_GetWindowRelativeMouseMode(window);
+                    SDL_SetWindowRelativeMouseMode(window, !relative);
                 }
             }
         }

On Windows the cursor visibility doesn't affect the behaviour, you can escape the constraints by clicking on any area of the child window during relative mode. Centering mode doesn't seem to affect this behaviour other than if the child window happens to be under the cursor while relative mode is active on parent window, any clicks will disengage the relative mode temporarily.

I can't seem to reproduce this on X11, I must've tested this under XWayland instead where having cursor visible can interact with the child windows, but not when it's hidden.

[slouken]

Thank you for the repro steps. Conceptually what's happening is correct. The mouse has a position, that position might be over a child window. If the child window is clicked, it will take focus, removing focus from the parent, and disabling relative mode until the parent gets focus back.

What's surprising here is that you don't necessarily expect the mouse to have a position when it's in relative mode, so you don't know when this behavior might be triggered.

I'm not sure how best to approach this. You'll notice this also happens if there's another application with a notification window that floats above your window (I tested this running testsprite --always-on-top)