Two Foreground Windows

In general, I've found that window management in OS X is still extremely buggy, particularly if you use spaces. Windows open in the wrong space, switching to an app with ⌘-Tab opens the wrong space, opening a link from another app in a browser opens the wrong space, dialog boxes that make a window modal are opened in the wrong space (and then often can't be activated at all), regular floating windows open in the same space as full-screen windows and break the whole window management, you can end up with windows that can't become the foreground window, you can end up in a state where no windows can be the foreground window... It's an absolute joke.

How exactly does one make a bug like that? It takes effort. After all, the obvious thing would be for the Window manager to have a unique global (!) variable pointing to the "foreground window". Then it's easy to pass events like key-presses to the "foreground window". For this to happen, they must instead have a linked list or array pointing to the windows, and a flag associated with each stating that it's a "foreground window". Why?

And do it again you will have three foreground windows ;)

"How exactly does one make a bug like that?"

"We're already storing the z-order of windows. We don't want the z-order to go out of sync with the active window, so we normalize the data model. The window with the highest z-order is necessarily the active window."

"Two 'foreground' windows" does not necessarily mean two key windows and the responder system (or window management in general) getting confused which to send events. It's a bug in the window state management, where the text field somehow confuses the window, and seems to break its state management, because even when that window becomes key again, it doesn't respond to some events, such as CMD+W. It could even be a Finder bug, rather than an AppKit one.

@Plume: I don't think it can be the z-order since you can have things float in front (e.g. the character input panel, or a video panel) that aren't selected.

@Leo: odd...

Windows’ Z order is also defined, in part, by each window’s level:

https://developer.apple.com/documentation/appkit/nswindow/level-swift.struct?language=objc

So it is definitely possible to have a window on top that is not the active/key window. For instance, you can float a note window on top, but it won’t remain key if you select another window. The desktop window can become key, but will never go above other windows, etc.