When I’m using Visual Studio, I often press the F7 key to start a build. But, a few days ago, I accidentally tried to do that when a taskbar item context menu was focused. What happened was this:
‘That doesn’t look like it’s supposed to happen’, was the first thing that came to mind.
As it turns out, F7 behaves similarly in almost anywhere UWP-based, such as in the taskbar calendar:
Or in a smaller context menu:
Apart from the obvious problem of the dialogue box not fitting in many of these places, turning on caret browsing in these examples doesn’t do anything useful – there’s no selectable text, and no cursor that appears.
But the problem is even worse in the start menu. If you’re unlucky, you’ll get this after pressing F7 (after first focusing something in the start menu):
This start menu is broken: most interactions don’t work, and it stays like this after closing and reopening it. The Escape key does get you out of this state if it’s one of the first things you try. But once you’ve closed and reopened the start menu in the broken state, the Escape key doesn’t help. The only way out is terminating explorer.exe and restarting it using Task Manager, or logging out and back in again.
The reason the start menu breaks in this way is that the caret browsing dialogue box is in the centre of the screen and is clipped out of view (as it doesn’t overlap with the start menu). If your settings are such that your start menu reaches the centre of your screen, you’ll see the dialogue box, and things aren’t as bad:
There are years-old references to these problems online (seemingly in one case from someone with a stuck F7 key), so it’s not new. I was also able to reproduce it in a clean installation of Windows 10 22H2 in a virtual machine, so it’s unlikely to be something peculiar to my installation.
On the plus side, I wasn’t able to reproduce it in Windows 11 22H2, so perhaps it has been fixed there (not that I’m in any rush to upgrade my main desktop...)