bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

>> With emacs -Q evaluate
>> (progn
>>    (setq pop-up-frames t)
>>    (load "~/with-temp-buffer-window.el")
>>    (shell))
>> type C-x C-c, and tell me what happens.
>
> Same behavior as the other emacs -Q recipe that manifested the problem:
>
> The question about killing processes is shown in the minibuffer of the frame
> with buffer *shell*.  Buffer *Process List* is popped up in a new frame, which
> is apparently selected for focus (by MS Windows).  Typing yes/no has no effect
> and there is no feedback, presumably because the wrong frame receives the 
input.
>
> (I cannot tell the order between the behavior described in the first and 
second
> sentences.  They seem to happen about the same time)
>
> And if you click mouse-1 in the echo area of the *Process List* frame then
> *Messages* is popped up in a new frame, confirming that there is no active
> minibuffer there.
>
> So now we have two recipes from emacs -Q, one with the code you sent.

This means that we have two different systems.  Here (Windows XP SP2)
the scenario above makes the *shell* buffer partially hide the *Process
List* buffer and typing yes/no has the desired effect.  Now we can only
wait till someone confirms either your or my behavior.

BTW, is it possible that Cygwin interferes here?  With Cygwin (rootless)
you apparently can't pop up an existing frame, see

http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00364.html

> BTW, if, after the kill-processes question is posed, I hit C-x C-c again (no
> reason to do that, but I did, just to see) then I get this message:
>
>   "window-normalize-window: #<window 8> is not a live window"
>
> and the frame with *Process List* disappears.
>
> Dunno whether this extra info helps at all, but I found it curious behavior.

It's a leftover from `quit-window'.  Thanks for noticing.

martin