bug#22068: 25.0.50; Delayed reaction to switching frames?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 02 Dec 2015 11:05:37 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 22068@debbugs.gnu.org
> 
>  > No, doesn't help.  I mean, when moving the mouse over, it still takes
>  > half a second for the frame highlighting to change, indicating the
>  > changed focus from the view of the window manager (I guess).  So I
>  > cannot vouch that the window manager isn't involved in the delayed frame
>  > switch.
> 
> I just tried with xfwm4.  Here a focus_delay of 185 (ms I presume)
> behaves as expected while a delay of 1850 shows the behavior you
> describe.
> 
>  > And indeed: the strange switch-frame- keyboard echo
> 
> ... which happens also when the prompt appears in the frame the mouse
> moved to and I now move the mouse back to the other one - I always
> wondered how to get rid of them ...
> 
>  > as a reply to the
>  > "changed on disk; really edit the buffer?" prompt in connection with the
>  > minibuffer (and actual keyboard focus) staying in the old frame in spite
>  > of the mouse pointer and the focus highlighting having moved over: that
>  > remains the same even if I keep the apparently perceived order of
>  > events: I cannot switch frames in reply to the "really edit the buffer"
>  > prompt.
> 
> All this seems very hardcoded in choose_minibuf_frame.

Could this have something to do with the fact that read-char-choice
calls read-key-sequence-vector with the CAN-RETURN-SWITCH-FRAME
argument nil?