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 124582 - Shift-arrow to move window to screen edge not working as documented
Shift-arrow to move window to screen edge not working as documented
Product: metacity
Classification: Other
Component: general
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 95067 157826 (view as bug list)
Depends on:
Blocks: 155458
Reported: 2003-10-14 15:47 UTC by korn
Modified: 2005-11-19 17:15 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description korn 2003-10-14 15:47:35 UTC
The GNOME accessibility guide describes how windows should get moved from 
various commands on the keyboard.  See

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.
Comment 1 Elijah Newren 2004-11-06 18:39:31 UTC
*** Bug 95067 has been marked as a duplicate of this bug. ***
Comment 2 Elijah Newren 2005-01-26 18:00:19 UTC
*** Bug 157826 has been marked as a duplicate of this bug. ***
Comment 3 Elijah Newren 2005-01-26 18:02:07 UTC
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

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.  ;-)
Comment 4 Elijah Newren 2005-10-23 16:01:40 UTC
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

process_keyboard_move_grab() calls
meta_window_update_keyboard_move() which calls
warp_grab_pointer() which calls

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

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?
Comment 5 Havoc Pennington 2005-10-23 17:30:06 UTC
It sounds like a plausible solution to me. Safe, I don't know ;-)
Comment 6 Elijah Newren 2005-10-24 01:29:27 UTC
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

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.

Comment 7 Elijah Newren 2005-11-19 17:15:51 UTC
[Cue Wizard of Oz music]

Ding! Dong!  The bug is dead!
The wicked bug,
The wicked bug,
Ding! Dong!  The wicked bug is dead...