| Date: | February 25, 2015 / year-entry #42 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20150225-00/?p=44593 |
| Comments: | 31 |
| Summary: | 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... |
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:
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)
Comments are closed. |
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?
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.
@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).
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.
So tell us Raymond, why the taskbar button has to be a separate window?
@alegr1 Uhm, a taskbar button isn't a separate window.
@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.
@DebugErr:
"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.
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.
@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.
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?
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.
@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.
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.
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".
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).
@alegr1 A control can't capture the mouse? Is it solved differently from classic -> Aero style? I don't see the "windows". :/
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.
@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.
@DebugErr:
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.
@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
@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.
@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
@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
@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'?
@Deltics: "everything is tickety-boo"? Wow, I never heard that before. I learn new things all the time here!
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.
@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.
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).
@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.
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.