GNOME Bugzilla – Bug 338361
Keyboard commands and sloppy focus
Last modified: 2020-11-06 20:05:12 UTC
1. Enable sloppy focus 2. Hit a keyboard shortcut to toggle the maximization state of a window Dependent on your mouse cursor position: 3a. The window keeps focus (if the cursor is still in the window after the "restore") or 3b. The window looses focus (if the cursor has left the window area after the "restore") I would expect that the window I'm operating on always keeps the focus after I resize it.
This should be pretty easy to fix. Since you're using the keyboard to navigate (Alt+F5 or Alt+F10), that means mouse_mode should be turned off. So, the handle_*maximize() functions in metacity/src/keybinding.c just need to be updated to reflect this. do_handle_move_to_workspace() provides a good example of how this is done. Adding the gnome-love keyword.
(In reply to comment #1) > This should be pretty easy to fix. Since you're using the keyboard to navigate > (Alt+F5 or Alt+F10), that means mouse_mode should be turned off. So, the > handle_*maximize() functions in metacity/src/keybinding.c just need to be > updated to reflect this. do_handle_move_to_workspace() provides a good example > of how this is done. Adding the gnome-love keyword. > Hello, I've tried following your comment, but I'm not sure I fully understand. Does setting mouse_mode to FALSE prevent any updates of the window state according to the mouse? I've tried setting window->screen->display->mouse_mode = FALSE in handle_toggle_maximize() (which is what do_handle_move_to_workspace() is doing), without any success. I've also tried to focus the window after (un)maximizing it with meta_window_focus (window, meta_display_get_current_time (window->display)); but the window behind the mouse pointer still recieves focus regardless. Any pointers would be appreciated :)
As per discussion in irc with Johannes, I was wrong about the fix. We need to have some way of ignoring the EnterNotify event generated by this unmaximization. The sentinel could do that, but it might be ugly as just sticking a meta_display_increment_focus_sentinel() in the keybinding handler function will result in getting the PropertyNotify for the sentinel too soon. Further, I'd really like to nuke the sentinel as it just results in race conditions when the user moves the mouse at about the same time (i.e. we tend to get the PropertyNotify later than we'd want). We discussed the possibility of turning off EnterNotify events until the mouse moved, and using MotionNotify to turn them back on. However, there's one big problem: For some reason I can't figure out how to get all relevant MotionNotify events. Also worth noting is that there'll still be a problem even if I could, though very rare (if at the same time the window is minimized the user starts moving the mouse, and the window under the mouse was an override redirect window (so that we don't get MotionNotify events), and the user moves the mouse into a new window but just enough to trigger an EnterNotify without triggering a MotionNotify, then the window entered wouldn't get focus like it should). So, since I have no clue how to fix this but it obviously isn't easy, I'm removing the gnome-love keyword.
There's no way to disable ANY focus changes at all between the keypress and the moment the resizing has finished? That would cover this case, I think...
Unfortunately, no it wouldn't cover this case. After we've resized, we tell X about the new size, X updates all the windows, and notices that the mouse enters a new window and sends us an EnterNotify, which we respond to by focusing the entered window (just as if the user had moved the mouse into it). The EnterNotify happens AFTER metacity is "finished resizing". We need a way to filter that EnterNotify event out without also filtering out EnterNotifys that we want. An alternative idea that I thought of was to query for the mouse position and ignore EnterNotify events until we receive one with a different mouse position. This might work well enough, but (a) it's an additional roundtrip to the server and (b) is probably a race condition itself since we'd be getting the mouse coordinates at the time of the query rather than the mouse coordinates at the time the minimize-window-shortcut was pressed.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.