Why does the mouse cursor jump a few pixels if you click on the very bottom row of pixels on the taskbar?

ABCDSchuetze discovered that if you click on the very bottom row of pixels of the taskbar, the mouse cursor jumps up a few pixels. Why is that?

In order to take advantage of Fitts's Law, the bottom-most row of pixels on a bottom-docked taskbar are clickable. Even though they are technically on the dead border of the window, the taskbar redirects the click to the button immediately above the border. But then you have this problem:

  • User clicks on the border pixel between the button and the edge of the screen.
  • The taskbar remaps the click to the button, thereby activating the button.
  • The button takes capture because that's what buttons do when you click on them. This allows you to drag off the button to cancel the click.
  • But wait: Since the mouse is on the border, it is already outside the button.
  • Result: The button cancels immediately.

The short version: Clicking on the Fitts's edge causes the button to be pressed and then immediately canceled.

The fix is to nudge the mouse back inside the button when the click begins.

Comments (31)
  1. Justin says:

    I have a similar 'feature' I have been wondering about… why do 'No Responding' windows on some versions of Windows jump down and the right when they get 'grayed', and then jump back with they start to respond again. Is this a bug or a real feature?

  2. Jonas says:

    It seems to be "broken" with the taskbar on the left side and classic windows theme in windows 7: the cursor does jump a few pixels inwards, but it does not actually jump onto a button. So it does not help at all; all it does it take away the focus of the current window.

  3. Nick says:

    @Justin: Just a guess: I'm betting the not-responding window renders its chrome outside of its declared borders so when it goes not-responding, the window manager renders it with its declared borders (see also: if something like Outlook 2013 stops responding, the default Minimize-Maximize-Close buttons ride overtop the custom ones rendered by Outlook).

  4. Yuri Khan says:

    It also was broken on Windows XP when the taskbar was resized to several rows. Clicking in the bottom left corner moved the cursor up and to the right to the point where the Start button would be if the taskbar were one row high; but with several rows, the button was higher up so the click went to nowhere.

  5. alegr1 says:

    So tell us Raymond, why the taskbar button has to be a separate window?

    [What would be the point of writing a standard button control and not using it? -Raymond]
  6. DebugErr says:

    @alegr1 Uhm, a taskbar button isn't a separate window.

  7. DebugErr says:

    @Nick Yeah, as far as I remember, wasn't that called ghosting the window frame? You can even turn that off for your window with some method I forgot.

  8. alegr1 says:


    "The button takes capture because that's what buttons do when you click on them." Capture is taken by a window, not by some random screen area.

  9. Mark says:

    Yuri Khan: that's not broken, there's just no button to receive the Fitts-law click, same as if you click towards the right end on a default-layout task bar when there aren't many applications running. It would be pretty weird if clicking all the way down in the bottom right acted like you'd clicked a chunk of the way up the screen.

  10. Joshua says:

    @Jonas: works for me (I always run classic theme as the accessibility settings I use are completely incompatible w/ Aero).

    @DebugErr: Oh yes it is.

    I'd have solved the problem by making the buttons flush with the bottom and left of the screen (and maybe using a custom draw to move the border back) but that's just me.

    @Justin: Because the Not Responding is actually a window owned by Explorer. The original window never moved.

  11. Muzer says:

    Just tried this on the machine I happened to be using now and I can't get the jump to happen. The button gets clicked anyway and the clickable area appears to extend to the very bottom of the screen. It's running Windows 7. Does it not happen there or something?

    [You have to be running a theme where the buttons don't go all the way to the bottom of the screen. -Raymond]
  12. NoRepro says:

    I am using Windows 7 and I don't see the cursor jumping.  I wonder if this has changed in service pack, if I am doing it wrong.

  13. @Muzer, @NoRepro: The Aero/Modern themes work differently and don't exhibit this behavior (which makes sense, since the buttons actually do stretch to the edge of the screen).  If you want to reproduce it, you can stop the Themes service.  This will revert back to the Classic theme, which has this behavior.

  14. Nico says:

    I seem to remember seeing this as far back as Windows 95.  If you clicked the very bottom-left pixel on the screen, the mouse would jump about 5 pixels up and to the right, to depress the Start button.  At the time I recall thinking how much I appreciated the shell behaving like this, and not just ignoring the click because it wasn't technically on the button.

    No idea if it's related, but the top-left and top-right handling of the System menu and Close buttons for maximized windows are also great.

  15. Deltics says:

    Hmmm, doesn't seem to quite work as intended on the system I am currently on.  Windows 7, Classic theme, Taskbar docked to right edge of screen.

    If I click to the RIGHT edge then the cursor jumps LEFT into the task bar button (a minimised app) and everything is tickety-boo.

    But if I click on the BOTTOM edge, the relevant "button" is "Show desktop", and the behaviour is not quite right.  The mouse cursor does indeed jump up, but the "Show desktop" button (now under the moved mouse cursor) is NOT activated (pressed).

    The result is that my mouse button is in the down state, with the cursor over a button which has captured the input and is focused but is not in the clicked "state".  i.e. releasing the mouse button at this point does not have the effect of having clicked the button.

    In order to actually have the button respond as clicked I must click (mouse cursor jumps), release (button release capture) then click the mouse again – the button then finally becomes "clicked".

  16. Deltics says:

    Even more odd – if I click at the TOP (where the "Start" button is) then the Start menu activates and displays as if I had clicked on the Start button, but the mouse cursor does NOT MOVE at all.

    Or at least, does not move until AFTER I have released the mouse, at which point it jumps DOWN/LEFT (depending on whether I clicked on the TOP or RIGHT edge of the Start button area (the button itself does not extend the full width of the vertically docked Taskbar so the mouse cursor movement in this case often does not place the mouse over the Start button at all, yet the behaviour is as if it had).

    Whatever the reasons for implementing this mouse nudge, it appears that the behaviour of the area under the mouse is not actually contingent on the position of the mouse, rather the mouse is being moved in order to attempt to maintain consistency of position w.r.t behaviour (not always successfully).

  17. DebugErr says:

    @alegr1 A control can't capture the mouse? Is it solved differently from classic -> Aero style? I don't see the "windows". :/

  18. Jonathan says:

    I'd noticed that as well. It's limited to Classic theme, and all post-classic themes (XP Luna, Vista/7/8 Aero) have their taskbar buttons extend to the very edge.

  19. Neil says:

    @Nico It doesn't work for me in either Windows 95 or Windows 2000. Since those OSes only had the one theme then I guess there was no inconsistency to resolve.

  20. sense says:


    A button is a "window". In fact an edit control, combobox, … all are "window"s. They have a hwnd (handle to window), and all are created using "CreateWindow".

    Maybe you're mistaken by the term's usual meaning. It's a standard term in Windows to refer to all these things, in addition to forms and dialogs (i.e. top-level windows) that you usually call a window.

  21. DebugErr says:

    @sense yeah I know the handles.

    I just meant that a taskbar button isn't a "window" with a hidden chrome or whatever. I know the start button is however since this article: blogs.msdn.com/…/10267063.aspx

  22. Justin says:

    @Joshua : So when a app window gets the whitewash effect it is in fact been replaced by an Explorer owned window then? Since that the Not Responding thing I mean.

  23. Bob says:

    @Deltics:  There's a story in the site archives which partially explains what you are seeing.  Windows telemetry revealed that the overwhelming majority of users have an always visible taskbar at the bottom of the screen.  The below reference shows that 5% of users autohide the taskbar & 1.6% of users have moved the taskbar away from the bottom.  At most 0.2% of users have a configuration similar to yours….thus it gets a low percentage of the testing.

    My current desktop configuration has 3 monitors in a horizontal row, the left one is portrait orientation, the other two are landscape.  The taskbar autohides on the right edge of the center monitor.  This setup exposes many bugs in Windows 7 & in application software I use, but overall the trade-off is worth it.

    Ref:  blogs.msdn.com/…/user-interface-starting-launching-and-switching.aspx

  24. Erik F says:

    @Justin: Explorer doesn't own the window; the window manager does (a subtle but important distinction!) See blogs.msdn.com/…/let-there-be-hangs-part-1-not-responding.aspx

  25. Justin says:

    @Erik, That is what I understood it to be… So it just that the Window position for the App window is wrong then, and hence the ghost 'jumps'?

  26. DWalker says:

    @Deltics: "everything is tickety-boo"?  Wow, I never heard that before.  I learn new things all the time here!

  27. Gabe says:

    I just checked on Win7 running Classic, and while the taskbar buttons are not themselves individual windows, they are collectively represented by a single window called "Running Applications" with the class MSTaskListWClass.

    Actually, they appear to be represented by two windows, because that window has a parent with the same dimensions and location (and caption), but being of the class MSTaskListSwWClass.

  28. Yuri Khan says:

    @Mark “that's not broken, there's just no button to receive the Fitts-law click”

    Then there’s no reason to jump the mouse cursor up three pixels if there’s no button to receive the click.

  29. ender says:

    Speaking of mouse pointer jumping, I noticed that when I'm connected to a some 8.1 computers with Remote Desktop, if I right-click the Start button, the mouse pointer jumps about 5 pixels to the right and up, regardless of where I'm clicking (if I click near the top edge, the pointer will move out of taskbar area).

  30. moobin says:

    @ender It jumps to highlight the bottom menu entry of the menu that pops up when you right click the start button. I don't know why it thinks that is something that is necessary though.

  31. 640k says:

    How hard is it to make an OS with a start menu button covering the most bottom left pixel? This shouldn't be hard. This should NOT require hacks like moving the mouse pointer. Programmatically interfering with how the user wants to position the mouse pointer is BAD.

    [The visual designers have their own ideas that do not necessarily take Fitts's Law into account. See: Round Start button. -Raymond]

Comments are closed.

Skip to main content