On Windows, at some stage, it was decided to allow one application to steal user focus from another application. That was a bad design decision, but one that it might be too late to undo, even Microsoft's own software relies on the ability to shift focus onto some inane popup.
To use an analogy, imagine how you'd feel if on Android/iOS you were in one app and without warning another app just started and took focus. You'd be super mad. But on Windows that is so common we have blinders on to it.
There's a particularly obnoxious bug still in Windows today related to this. If the iTunes or Java background update task kicks off, you'll never see it, but it will shift keyboard focus to nothing. Visually it causes a slight flicker, but if you type the keypresses go nowhere since focus shifted to a now closed window (a window that was open for less than a second).
Even Windows UWP apps aren't immune. While one UWP app cannot easily steal focus from another, Win32 API applications (and Windows' own processes) continue to steal focus. Applications that want focus should just blink on the taskbar, focus should only change when the user changes it.
Microsoft thinks they fixed this (see SetForegroundWindow[0]):
> An application cannot force a window to the foreground while the user is working with another window. Instead, Windows flashes the taskbar button of the window to notify the user.
But for whatever reason the issue remains. Particularly the keyboard input disappearing into null behavior I described above.
[0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
Qt, steadfast in its duty to be as annoying as possible, pretends it is part of the foreground app when you call activate() by calling AttachThreadInput [1].
[0] Documented heuristics, even. https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... [1] https://github.com/qt/qtbase/blob/5.11/src/plugins/platforms...
Linus Torvalds said in one of his talks that it is his belief why GNU-Linux on the desktop hasn't taken off.