This seems to be an artifact of OS's that also decide that "window on top must have keyboard focus" (i.e., MSWin is very bad in this regard). Because the pop-u

This seems to be an artifact of OS's that also decide that "window on top must have keyboard focus" (i.e., MSWin is very bad in this regard). Because the pop-up dialog must be "on top" to be a pop-up, the OS's built in design of "window on top must have keyboard focus" results in the popup gaining keyboard focus, even if you are actively typing into another window at the same time. On my Linux system, I run Fvwm2, and because on X the decision to grant focus to a window lies with the window manager, I can control who gets focus via my Fvwm2 config. I have Fvwm2 set for focus follows mouse so unless a popup happens to appear, directly under where the mouse cursor happens to be at that moment, the popup can appear, and be "on top" and my keyboard focus is unchanged. I also have Fvwm2 configured so that a window gaining focus does not in any way change its order in the stack, so I can focus, and type, into a partially obscured window, without ever moving that window up/down from where it sits. An old version of OpenOffice (I think back when it was still called StarOffice) had decided at some point that if the mouse cursor so much as brushed across its window that it would pop itself to the top and take keyboard focus. That happened about two times, then I added a couple lines to my Fvwm2 config to take away StarOffice's ability to both take focus and to raise itself to the top, and it became a properly behaved program that stayed put until I told it specifically to move to the top. These kinds of irritants can be fixed, but only if the environment one uses gives one the ability to control these miss-behaviors.