After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 338361 - Keyboard commands and sloppy focus
Keyboard commands and sloppy focus
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
trunk
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2006-04-13 15:00 UTC by Wouter Bolsterlee (uws)
Modified: 2020-11-06 20:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Wouter Bolsterlee (uws) 2006-04-13 15:00:47 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.
Comment 1 Elijah Newren 2006-04-13 16:11:07 UTC
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.
Comment 2 Johannes H. Jensen 2006-04-30 01:12:57 UTC
(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 :)
Comment 3 Elijah Newren 2006-05-01 17:10:19 UTC
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.
Comment 4 Wouter Bolsterlee (uws) 2006-05-01 17:36:49 UTC
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...
Comment 5 Elijah Newren 2006-05-01 17:48:45 UTC
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.
Comment 6 André Klapper 2020-11-06 20:05:12 UTC
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.