GNOME Bugzilla – Bug 436416
Opening toolbar menu with hotkey causes mouse pointer change
Last modified: 2016-05-24 11:05:29 UTC
Please describe the problem: In some situations, when using hotkeys to access the menu, the cursor may incorrectly change the icon to "resize". Steps to reproduce: 1. Start Nautilus (For example) 2. Position the cursor outside of the window 3. Press Alt+F to pop up the File menu Actual results: The mouse cursor turns to a "resize" icon. The direction of the resize depends on the cursor's position relative to the window. Expected results: The cursor should not be affected by this action Does this happen every time? Yes Other information: I am using GNOME 2.18.1
I am referring to the MOUSE cursor in the description. Not the caret.
I can reproduce by moving the mouse pointer out of the app window before using the hotkey. works with any gtk+ menu bar mclasen, gnome-love bug??
How odd. I don't think there is anything gnome-love specific about this bug. It is certainly something we should fix for the next release. Patches are always appreciated, of course.
Pretty sure this is a metacity problem. GTK+ does not do any gdk_window_set_cursor calls in this scenario, and the problem does not happen e.g. with twm.
I narrowed this down to metacity's frame.c http://svn.gnome.org/viewcvs/metacity/trunk/src/frames.c?view=markup meta_frames_enter_notify_event() is called when the menu is opened. Inside, the get_control() function decides what cursor icon should be displayed. Its "resize" cursor checks are very simplistic - "If I'm to the right of the window's edge, draw a RESIZE_EAST cursor" - it assumes get_control() is only called when the cursor is actually inside the window or on its edge. When I disable the calls to get_control and meta_frames_update_prelit_control in the function mentioned above, it works, but I'm not sure what else is broken, or why those calls are there. Related revision: http://svn.gnome.org/viewcvs/metacity?view=revision&revision=302
Thanks for tracking it down this far.
Don't have any time to check into it and verify, but from Ori's extra details I bet this is being caused by us getting a NotifyGrab/NotifyUngrab EnterNotify and us responding to it. The intent was really to only worry about EnterNotifies with a normal crossing, so filtering out GDK_CROSSING_GRAB/GDK_CROSSING_UNGRAB enter notifies may fix this (much like bug 101190...)