Ask HN: Details behind years old Windows taskbar bug?

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.

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.

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.

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!

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?

I am currently on a fairly fresh install of Windows 10 (past week or so), but I do have some of my dev environment installed, so not completely clean. It started happening pretty soon as always for me.

I'm starting to think it may have something to do with the way some people interact with the UI, as some people do not get it at all and some, like me, get it often.

Related SuperUser question (from 2009) including demo and workaround:

http://superuser.com/questions/61833/windows-7-taskbar-icon-...

Also notable that these questions still pop up for Windows 10 even now. When they had the UserVoice set up for Windows 10, this bug was there as well. I think the UserVoice is gone now though.

One other "bug" I wish they would fix is when you change virtual desktops, the taskbar items reset, apparently, to the order the windows were opened in. Messes me up really bad as I keep the windows in specific order.

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.

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.

How exactly does one reproduce this?

I think it has happened to everybody, but I can't reproduce it reliably. It happens to me at random, if I don't reboot the computer for days it will always appear.

You can kill explorer.exe to fix it.

I left my Windows PC on for years at a time and didn't notice this. I wouldn't be surprised if it was non-deterministic.

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.

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.

I usually reboot at that point. This issue has been in Windows since at least Win2000.

[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.

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.

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?

You know how when you hover over a taskbar button, it highlights and a little preview pops up? When it breaks, I get the highlight, and the popup, but when my mouse moves away, they both stay there. Usually, I can move my mouse back and out quick, and the preview popup goes away and stays gone, but the highlight stays.

You can temporarily fix it by right-clicking any taskbar button while holding shift. It works for me, until it's back again.

I've seen it in XP and 7, but not in 10.