Why do I have to hit an arrow key before a keyboard-initiated Move operation will follow the mouse?

TehShrike wonders why you have to hit an arrow key before a keyboard-initiated Move operation will follow the mouse.

I don't know, but I think it's just a bug. Mind you, it's a bug with extraordinary seniority (probably going as far back as Windows 1.0).

The Move and Size commands from the system menu are operated by the same common function, and the keyboard-initiated Size command requires you to hit an arrow in order to specify which edge you are trying to resize. The Move command doesn't need to let you pick a side (since moving is independent of sides), but the common helper function waits for the arrow key regardless of the underlying operation.

Comments (44)
  1. alegr1 says:

    More likely it's an usability feature.

  2. CmdrKeene says:

    I don't see how this impacts (negatively or positively) usability.  If the mouse immediately gripped the window, the keyboard user could still ignore it and continue using the keyboard.  I'm included to agree with Raymond here.

  3. Brian_EE says:

    I never noticed this behavior before, but just tried it now (XP). Interesting.

  4. Damien says:

    @Brian_EE – you've never ended up with an annoying window sitting off-screen that you need to get back on screen?

    I thought that, and the fix (Alt-Space, arrow key, move mouse) were universal experiences.

  5. Tim says:

    I wonder if some previous version of Windows only allowed you to move windows with the arrow keys when you initiated the move from the keyboard. Then it wouldn't really matter that the move wasn't actually started until you press an arrow key.

    The bug would only manifest when mouse support was added, because you would expect to move to start when the command was invoked instead of when you press an arrow key.

  6. Dmitry Onoshko says:

    Tested that with WinXP SP3. Well, it only worked a few times with calc.exe. Then I've tried to resize Notepad.exe's window and the additional arrow key is not needed for some reason. I think, I'll try this again a bit later, after rebooting the computer.

  7. JM says:

    You just know that if anybody ever comes around and fixes this minor little silly thing, somewhere, some value-added application by BigCorp will break, because it somehow relied on this behavior. Maybe the developer couldn't find MoveWindow but did know SendInput… something like that.

  8. Gabe says:

    Tim: Windows had mouse support from day-1, but it had to always be optional since you couldn't expect all users to have a mouse in the mid-80s.

    One of the great things about Windows is that to this very day there are very few things in that can't be accomplished with a keyboard (changing the width Explorer's folder tree or viewing its tooltips come to mind).

  9. Mashmagar says:

    The Move command definitely confused me. I kept trying to drag the window with the mouse and it never worked. It was several years before somebody showed me I could move it with arrow keys. I assumed that was the only option.

  10. BJ says:

    @Gabe – the fact that you can use a keyboard for (near enough) to everything – even in Win 8 / Server 2012 – is incredibly useful when you're working on industrial / embedded computers.  Even if they have a mouse / trackball / touchpad, if it's been sitting in a factory for three years, it doesn't work.  The fact you can walk up and do everything necessary on the keyboard is a huge benefit.

    Up until Win 8, Start, right, right, right, Enter shuts down without a mouse or a monitor (if it is unlocked).  Sometimes remote desktop services can be running well enough to allow you to connect, but not serve up an image.  That's OK, Log in, Start, right, right, right, Enter shuts down (and right, right, right, up, up restarts).  Yes you can do it in Win 8 too, but the sequence isn't burned into my ROM yet.

  11. John says:

    @Damien I've always used the right click (Shift+Right Click in Win7) to get that menu, I didn't realize Alt+Space was the shortcut for it. Now days when it happens I use the Aero Snap hotkeys (Win+[Left,Right,Up,Down]) which is awesome. Aero Snap was in my opinion the single biggest usability enhancement added in Windows 7 (although as Raymond pointed out a few years ago this was always possible, in Windows, it just didn't have the super cool hot key).

  12. CN says:

    Is the helper function in some sense still the same code, or has the bug/odd design decision been faithfully reproduced in one or more rewrites?

  13. xpclient says:

    In old Explorer, right clicking on that top-left icon of the Explorer window used to show the context menu for currently open location – was easier to target hot corner than precise positioning over an item to show context menu. Now it shows the window menu just like left click/Alt+Space does. :(

  14. MNGoldenEagle says:

    @xpclient: If you don't have anything selected, you could just press the Menu key.

    I always forget that key exists.

  15. Brian G. says:

    I've been wanting to ask exactly this question for a while, but I always miss the suggestion boxes. Thanks to TehShrike for covering for me! I'm somehow glad to learn that it's most likely a bug, not intended design.

  16. eggbox23 says:

    This comes in handy when you have a window that is off the screen; sometimes when you have a laptop that was connected to multiple monitors and then you disconnect those monitors and the window stays in the multi-screen location (off screen).  Alt+Space then M then ArrowKey allows you to simply 'pick up' the window with the mouse and move it on-screen, very useful and used many (many) times over the years.  It may be a bug but it is useful, please don't fix it!

  17. Muzer_ says:

    I remember being very confused by this feature when I was young. It was only a few years after I first discovered it that I actually figured out how to use it.

    I doubt it goes back to Windows 1 – didn't that not have resizeable windows? Or maybe it was in the old version of Windows 1 that did… I can't quite remember the history.

  18. Jeffrey L. Whitledge says:

    > the common helper function waits for the arrow key regardless of the underlying operation.

    I feel way better about having to press that arrow key now that I know there is *some* reason for it (even if it's not a good reason). Thanks for the explanation!

  19. Brian_EE says:

    @Damien – I always just Alt-Space X to maximize the screen, but that's not something I've run into enough to have had the opportunity to notice.

  20. Entegy says:

    @eggbox23 You can also just hit Win+Up/Left/Right arrow in Windows 7 and above. That initiates snap sequences, which if the app is off screen it will go to the closest monitor.

  21. CN says:

    Entegy. That doesn't work for non-resizable windows, which might include modal dialog boxes stopping your main application window from regaining focus.

  22. P says:

    I had always noticed that, but never asked myself about the reasoning behind that. I just press a key before moving the window via the context menu (mostly to find a lost window).

    What has really gotten me thinking about, is why half the cursor is displayed on each monitor when moving a window from one monitor to another, yet not when simply moving the cursor from one monitor to another.

    [Not sure what you're talking about. The cursor follows the caption bar. It doesn't jump to the monitor boundary. -Raymond]
  23. xpclient says:

    @MNGoldenEagle, Menu key only works if the focus is on the navigation pane. Right click on hot corner worked even if focus was in the file pane. Menu key in the right pane shows the directory background context menu.

  24. Marcel says:

    @P: Wow, very observant, I never noticed this detail.

    I guess that when MS introduced opaque window movement they just took a screenshot of the window, including cursor, and then hide the real cursor.

    [Move a window that is constantly updating (e.g. a clock or an animation). Notice that the animation continues, so it's not a snapshot. -Raymond]
  25. SimonRev says:

    Don't know why everyone here is against fixing the bug.  Presumably the fix would be to have the move command immediately start tracking the mouse rather than waiting for the arrow key.  This would be a substantial usability win in my book as the arrow key is not very discoverable.  I know that in Win98 you could use the Home key instead of an arrow, so when I moved to XP and had to use the arrow key I was stymied for a while (especially since it was my web browser that was stuck off screen :) ).

  26. Nick says:

    @BJ: I don't know about you but on my Windows 7 machine, Start, right, right, right, Enter puts my computer to sleep, it doesn't shut it down.

  27. SimonRev says:

    @Brian G:  My Win 7 machine with 6 monitors (and 2 ATI video cards) behaves like P's machine.  Also I cannot see the window tracking ahead of the mouse like you describe.  Interestingly if you drag a window so that the cursor is split between monitors then drop the window, half of the cursor immediately disappears.

    However, I have a huge piece of evidence to disprove the snapshot idea.  Change your Normal Select pointer to an animated cursor.  Note that while the window is moving the cursor remains animated, even when split between multiple monitors.

    I am going to speculate that when not dragging, Windows is using a hardware cursor of some sort, but when dragging it switches to a software cursor for some reason.  But I don't really know enough about that level of graphics to know if that is very good specultion.

  28. alexx says:

    Here's a bug I found recently on Windows 7:

    – Open Command Prompt

    – Click the Start button to open the Start Menu

    – Click the Show Desktop button to bring the Desktop to the front

    – Click the Show Desktop button again to bring the Command Prompt window to the front

    – Watch what happens to Command Prompt window

  29. alegr1 says:

    Here is a bonus question. Why does Windows (Vista+?) screw up the display resolution of a disconnected FUS session? And why it incorrectly recalculates SPI_GETWORKAREA after that?

  30. alegr1 says:

    The reason the cursor is immediately moved onto the caption bar on SC_MOVE, is that the move code needs to call SetCapture(), but it will only be effective if the cursor is over the window.

    Is SC_SIZE is selected, you can cancel the size by clicking outside the window before using any arrow key. I guess the same reason applies to SC_MOVE.

  31. Marcel says:

    @Raymond: No, P meant that when you move the cursor alone, it will either be on one monitor or the other, but never halve-halve on both. In Window-Move mode the the cursor will move seamlessly between monitors. I guess the hardware cursor thing could make sense, though I expected hardware cursors to have died along with SVGA cards.

  32. Random832 says:

    "Is SC_SIZE is selected, you can cancel the size by clicking outside the window before using any arrow key."

    Or, for that matter, by clicking _inside_ the window before using any arrow key. Also, it moves the cursor onto the caption bar again if you moved it between selecting the command and using an arrow key, so it didn't really need to move it the first time. I suspect this is because it moves the cursor twice (once to the center, and once to the edge) for moving, so it moves the cursor twice (both times to the caption bar) for resizing.

  33. Brian G. says:

    @P I think you may be observing video-driver-dependent behavior. I'm not sure about that. Anyway, I don't currently have a multi-monitor machine to test, but I have a good test for you to run to test your snapshot theory. I've observed taht if I grab a window in the vicinity of text (for example, just to the right of the vertical part of a letter), I can clearly observe that as I move the window, the window moves *ahead* of the cursor.

    I've observed this in Windows 7 x64 on NVidia graphics hardware. I think I've also seen it on 8. I just tested it on my work machine with XP x86 with old Intel graphics hardware, and it happens, but only a pixel at most whereas I've been able to get the window several letters ahead of the cursor on my home machine.

  34. Nick says:

    @alexx: I followed your steps-to-reproduce and didn't see anything of consequence.

  35. Brian G. says:

    @SimonRev thanks for testing that. Not that I'll ever do anything valuable with the information, but it's nice to have a bit of curiosity sated. *grin*

    Your hardware cursor theory is consistent with my (extremely limited) knowledge and observations.

  36. alexx says:

    @Nick: I forgot to mention that I was using Remote Desktop Connection when I found that bug. I'm not on Win7 right now, but maybe you could reproduce the bug at the console with Aero turned off.

  37. alegr1 says:

    >Also, it moves the cursor onto the caption bar again if you moved it between selecting the command and using an arrow key, so it didn't really need to move it the first time.

    It needs to call SetCapture *before* you hit arrow keys. Thus it needs to move the cursor.

  38. P says:

    @Raymond: I suppose you already understood it based on the other comments, but in case you didn't, this happens when you're dragging a window from one display to another. If you position the cursor just right, you will be able to see half the cursor on one display, and half the cursor on the other.

    This is different from the usual behavior, which is to show the cursor only on one display.

    I also assumed this would be a driver issue, but it has consistently happened on a bunch of computers with AMD, nVidia and Intel adapters. But even so, I don't think the drivers know anything about window dragging, so I tend to think this change in behavior is eventually initiated by Windows code, even though it may be implemented by driver code. (Note: I'm not a driver developer, so I have no idea what I'm talking about)

    [Okay, I see what you mean now. I originally thought you meant that the cursor jumped to the straddle point when you initiated the movie. What you meant was that if you are dragging a window with the mouse, then something funny happens when you move the cursor to the straddle point. I cannot explain. -Raymond]
  39. alegr1 says:

    >Reasonably enough, on the first boot after the hardware swap, Windows fell back to the VGA driver at 640×480.

    Windows 7 generic VGA driver can run 800×600, and possibly 1024×768.

  40. Zack says:

    This seems like the right context to complain about something that just happened to me: I upgraded the video card on a PC (running Windows 7) whose primary display is a TV — native resolution 1280×720.  Reasonably enough, on the first boot after the hardware swap, Windows fell back to the VGA driver at 640×480.  Then I downloaded the proper driver for the new card … and could not run its installer, because its "wizard" windows were too tall for the screen, and the advance-the-installation buttons, being as usual at the bottom of the window, were inaccessible.  To make matters worse, whoever wrote the installer had screwed up keyboard traversal; pressing Enter focused some random button in the middle of the installer, and the Tab loop did not include the "go on" button.  For the same reason, turning on the screen reader did not help.

    With some effort I managed to move the wizard so it was cut off at the *top* (you have to turn off "Aero Peek", and then use keyboard-initiated move, to make this happen at all) but then the *contents* of the window moved back down, making the button inaccessible again.

    In the end I had to bypass the installer and use the "Look for a driver in this directory" mode of the Device Manager.

    I'm not sure any of this is Microsoft's fault, but it sure was infuriating.

  41. ender says:

    @alegr1: it can run at even higher resolutions, but only if the display reports that it supports them. Since the display is a TV, it's quite possible that it doesn't report anything but 640×480.

  42. Zack says:

    Yeah, the only option in the resolution selection dialog (which worked fine) was 640×480.  That part, I am happy to blame on the TV.

  43. Mike Dimmick says:

    @Muzer: Windows 1.0 didn't have *overlapping* windows. I think it still had a Move command so that you could move a given window to a different part of the screen, though.

  44. Marc K says:

    @BJ: On Vista and newer (i.e. everything supported after 04/08/2014), you can hit the windows key, then type in "shutdown -s -t 0" and hit enter to shut down the computer.

Comments are closed.