GNOME Bugzilla – Bug 124582
Shift-arrow to move window to screen edge not working as documented
Last modified: 2005-11-19 17:15:51 UTC
The GNOME accessibility guide describes how windows should get moved from various commands on the keyboard. See http://www.gnome.org/learn/access-guide/2.2/keynav-11.html#keynav-14 Once a move is initiated with Alt-F7, the document specifies that Shift-arrow shall "Move the window in the direction of the arrow key to align it with the edge of the nearest window, panel, or screen edge." This implies that if the window is in the middle of the screen, Shift-right-arrow should move the window such that the right edge of the window is at the right edge of the screen, and the vertical position is unchanged. However, what is happening now is that any Shift-arrow keystroke will put the window into a corner. Thus left-right Shift arrow moves also change the vertical component, and up-down Shift arrow alter the horizontal component. At a minimum, either the code, or the documentation, should change. I believe the documentation is correct, and the code should change, as the documented behavior is what is expected.
*** Bug 95067 has been marked as a duplicate of this bug. ***
*** Bug 157826 has been marked as a duplicate of this bug. ***
Note that this applies for movement with the mouse while holding down shift as well as movement with the arrow keys (after pressing Alt-F7) while holding down shift. Also note that bug 157826 mentions, and I indeed can duplicate, that there's flickering occuring in that the window moves one direction and is shown and then immediately disappears and reappears after moving in the other direction; but of course, if we force it to only move in one direction as this bug is about, then that should take care of the flickering. ;-)
Another bug I started working on for the constraints_experiments branch (yeah, okay, so I'm doing some move/resize bugs that aren't necessarily constraints related, but it's part of just making sure that constraints.c gets sane input because it didn't use to and may still not be)... Anyway, here's how this bug happens: process_keyboard_move_grab() calls meta_window_update_keyboard_move() which calls warp_grab_pointer() which calls XWarpPointer() which generates various mouse events (EnterNotify last I tried, I'm guessing LeaveNotify, MotionNotify, and others are also possible) resulting in calling meta_window_handle_mouse_grab_op_event() which calls update_move() which, since the snap key is pressed tries to do a snap resize corresponding to the change in location of the mouse pointer from the XWarpPointer() call relative to window->display->grab_anchor_root_[xy]. I don't know what the right fix is, but my guess would be to have warp_grab_pointer() update display->grab_anchor_root_[xy]. Havoc: Is that safe?
It sounds like a plausible solution to me. Safe, I don't know ;-)
Updating display->grab_anchor_root_[xy] and display->grab_anchor_window_pos.[xy] seem to do the trick but leave some ugly flickering with the enter and leave notify events. A simple boolean seems to fix this up, though. I've done a fair amount of testing and read over lots of other related code and I think it'll be fine. I also fixed the mouse snapping weirdness that I mentioned in comment 3, which was one weird bug. It turns out that we would snap in x if the y position had changed at all since the beginning of the grab (not just since the last movement), and we would snap in y if the x position had changed at all since the beginning of the grab. I only fixed this on the constraints_experiments branch and I'm not posting a patch here, basically because I want to avoid merging conflicts and I think that branch is getting relatively close to being able to move towards HEAD (though there are a couple significant regressions I need to fix first...) If you want, I can attach the patch here anyway if you like, but it may make more sense to just wait for a general review of that branch. :-)
[Cue Wizard of Oz music] Ding! Dong! The bug is dead! The wicked bug, The wicked bug, Ding! Dong! The wicked bug is dead...