There is a long standing bug in Windows, where the hover state on taskbar items - highlight and a window preview - gets stuck after having the computer run for a while, as if the taskbar never notices the cursor leaving it.<p>I've had this bug on every single Windows version since Windows 7, on every single installation and every single Windows PC I've used actively.<p>Along the years I've seen people suggest all kinds of workarounds for this, but I've seen none that do more than temporarily fix the issue.<p>This bug has intrigued me ever since I noticed it being consistent across versions, and most recently I checked if it still applies to Windows 10 Anniversary Update, which it does. Why is it so persistent? Why did it survive the "should-not-call-it-metro" changes to the explorer shell?<p>Since there's often interesting discussion and insight on obscure bugs in Hacker News, does anyone have any insight on this? Has anyone ever debugged it?
It might be related to the TrackPopupMenu on notification tray workaround, where one must set themselves to the foreground window and post WM_NULL or other message in order for the window to be properly dismissed.<p>However that one in particular iirc has to do with the way input is handled among threads, and how Windows is careful with how activation / focus gets passed among processes.<p>Since the taskbar needs to do various things without taking input focus or capturing the mouse etc, I would assume the bug has to do with managing this obscure behavior, and missing a notification (or some obscure race condition?) that results in the taskbar not transitioning to the non-hover state.<p>Outside the taskbar you can often see these bugs in situations such as click, hold the mouse, then move outside of the window or have focus switched. Many times the capturechanged events or activation events do not end up handled properly -- trying to do all this without capturing the mouse or input is even more difficult, though I presume a simple timer would suffice.
If you can't reproduce it reliably and it's kind of rare... isn't that enough to explain it? :P First thing you need in a bug report is a reliable way to get it to happen!<p>Also having read Raymond Chen's "Old New Thing" blog for a while, it's very common that some third party software/extension does something insane with the desktop window and breaks things. It could be something like that. Can you reproduce it on a completely empty fresh install of Windows?
Related SuperUser question (from 2009) including demo and workaround:<p><a href="http://superuser.com/questions/61833/windows-7-taskbar-icon-highlight-sticks" rel="nofollow">http://superuser.com/questions/61833/windows-7-taskbar-icon-...</a>
I've seen pressed/depressed button state bug periodically in older versions of Windows (up to XP it seems). Sometimes multiple buttons in taskbar appeared in pressed state (should be one which is active).
Weird, I've had all sorts of bugs happen to me, but I've never actually seen this particular one happen across 4 or so systems.<p>As to your question, I figure it's the same as anything else in windows, legacy code. One library gets stacked on top of another, then another, and when the UI pulls from it, it drags up bugs from the entire stack.
There's a similar bug where a taskbar set to auto-hide will stop, well, auto-hiding. The recommended solution is to pop open Task Manager, find explorer.exe, and restart the process.
I have seen similar bug in probably all versions since XP, not sure about 10 though. Sometimes a hover-tooltip would not disappear after moving mouse out of taskbar or system tray item.<p>As I am using beefier hardware it gets more difficult to reproduce, but the general pattern is oversaturating I/O: have multiple memory hungry applications swapped out and try to bring them all back.
Drives me bonkers every few weeks. I set the task bar to "auto hide" and then it decides, at random, to never hide, pushing my Emacs mode line and the bottom few lines of text in the editor down under that useless thing.<p>I usually reboot at that point. This issue has been in Windows since at least Win2000.<p>[Some peer post says that killing explorer.exe fixes it. I'll try that next time]
I have no idea (don't personally remember encountering this), but the taskbar has changed very little since Win7 (the only significant changes have been improved multimonitor support and extending pre-existing features like jump lists and badging to support modern apps), so it's not surprising if bugs survived.
I've seen it for years on my Win7 install but yet to see it on my Win10 install, which I got in mid-to-late June. But yes, it's always frustrated me too and I don't know what's caused it.<p>I suspect it's one of those very low-priority bugs and thus never gets fixed.
Interestingly the dock in Mac OS X has a similar bug. I have to do a `killall Dock` from time to time to fix it.<p>My guess is there some kind of difficult to handle race condition around the states on this type of system UI, particularly for laptops that go in and out of suspend mode.
As soon as I read your title I thought it might be this bug. I get it maybe a few times per month in Windows 7. I have not seen it happen in Windows 10. You can fix it without rebooting or killing explorer.exe by shift+right-clicking on the taskbar item.
I read your bug description through a few times, I am struggling to understand what you mean. Are you saying the preview within the pop-up isn't updating after a while or something else entirely? Or that the box doesn't auto-close?