bug#17736: 24.4.50; *-mouse-1 acts on wrong frame

[Drew Adams]

> > 9. Select *scratch* frame.  `M-x', then `C-S-mouse-1' in
> >    *scratch*.  See message in both *Messages* and echo
> >    area (minibuffer frame): selected frame is
> >    " *Minibuf-1*".
> >
> > #9 is unexpected.
> >
> > Can you repro this?
> 
> Thanks for the recipe; I now see the behaviour you're describing.
> 
> > If so, we can talk about whether #9 should be expected or is a bug.
> 
> The thing is, in your setup, typing `M-x' selects the minibuffer frame
> -- the *scratch* frame loses focus.  So I agree with what Eli said
> earlier: I think this is consistent behaviour, and you have to examine
> the event you're getting to see what frame the user clicked in.
> 
> So I'm closing this bug report.

This is wrong, IMO.  I think you're missing the point.

Yes, `M-x' selects the minibuffer frame.  It does so
in ALL cases - in the case when the starting frame is
*Messages* as much as when the starting frame is
*scratch*.  That's 100% normal.

But THEN, if a user selects another frame, that frame
should be, well, selected - focused.  The behavior seen
for *Messages* should also happen for *scratch*.

A user should be able to switch frames whether or not an
`M-x' is in progress.  And she should be able to switch
frames, in particular, to do something that might affect
or inform the ongoing behavior of `M-x'.

A user can switch to another frame and then come back to
the minibuffer frame.  She can already do this for a
different frame from the one that initiated minibuffer
interaction (`M-x' in this case).  There's zero reason
why she can't do this also for that initiating frame (or
please supply a reason!).

There's no reason (or else please supply one!) why the
minibuffer frame should keep, and not relinquish, focus
when the user explicitly selects another frame.

I know that you guys are not used to interacting with a
standalone minibuffer frame.  But that should not limit
your ability to understand/imagine how it can be used.