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

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

[Drew Adams]

Put this code in a file:

-------------------------
(defun 1on1-emacs () ""
  (interactive)
  (setq default-frame-alist (list (cons 'minibuffer nil)))
  (setq pop-up-frames  t)
  (setq minibuffer-frame-alist 1on1-minibuffer-frame-alist)
  (make-frame 1on1-minibuffer-frame-alist)
  (setq minibuffer-auto-raise t)
  (setq w32-grab-focus-on-raise nil))

(global-set-key [C-S-mouse-1]
		(lambda () (interactive)
                   (message "FR: %S" (selected-frame))))
-------------------------

runemacs.exe -Q --debug-init  -l "onetest.el" -f "1on1-emacs"

C-x b *Messages*
C-x 5 2
C-x b *scratch*

You now have a frame showing *Messages*, a frame showing *scratch*, and
a standalone minibuffer frame.  Make the first two frames small enough
that you can see both of them and the minibuffer frame.

1. Click `mouse-1' in the *scratch* frame, or otherwise select it and
   give it focus.

2. Click `C-S-mouse-1' in the *scratch* frame.  You see the message
   indicating that this is the selected frame.  Click `C-S-mouse-1' in
   the *Messages* frame.  Again, the message indicates that the clicked
   frame is the (newly) selected frame.

3. Repeat #1, to select frame *scratch*.  `M-x', then click
   `C-S-mouse-1' in the *Messages* frame (*not* the selected frame
   before you clicked).  You again see a message indicating that the
   clicked frame (*Messages*) is the (newly) selected frame.

4. With *scratch* still the selected frame, `M-x', then click in frame
   *scratch* (the selected frame before you clicked).  The message says
   that the standalone minibuffer frame is the selected frame.

1-3 are normal.  #4 is the bug.  A command bound to `C-S-mouse-1' does
not act on the frame that you click.  The same behavior occurs if you
use `S-mouse-1', `C-mouse-1', or even `mouse-1' instead of
`C-S-mouse-1' in the recipe (but you may also need to set
`*-down-mouse-1' to nil).

In sum, a mouse click while the minibuffer is active does this:

* Acts on the clicked frame, if it was not the frame selected before
  activating the minibuffer (or if is is the minibuffer frame).  This
  is what I would expect.

* Acts on the minibuffer frame, if the clicked frame was selected before
  activating the minibuffer.  This is not what I would expect (unless
  the frame clicked is the minibuffer frame).

I would expect that the frame clicked always becomes the selected frame.
Is this expectation wrong?

I ask the question about whether the behavior should be exceptional this
way, because it is not new behavior: it is at least as old as Emacs 20.
It's not clear to me why Emacs behaves this way.


In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-06-01 on ODIEONE
Bzr revision: 117212 michael.albinus@gmx.de-20140601104945-g88x0mwrxorz302h
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Put this code in a file:
>
> -------------------------
> (defun 1on1-emacs () ""
>   (interactive)
>   (setq default-frame-alist (list (cons 'minibuffer nil)))
>   (setq pop-up-frames  t)
>   (setq minibuffer-frame-alist 1on1-minibuffer-frame-alist)
>   (make-frame 1on1-minibuffer-frame-alist)
>   (setq minibuffer-auto-raise t)
>   (setq w32-grab-focus-on-raise nil))
>
> (global-set-key [C-S-mouse-1]
> 		(lambda () (interactive)
>                    (message "FR: %S" (selected-frame))))
> -------------------------
>
> runemacs.exe -Q --debug-init  -l "onetest.el" -f "1on1-emacs"

This recipe just gives me an error:

1on1-emacs: Symbol’s value as variable is void: 1on1-minibuffer-frame-alist

Do you have a working recipe that demonstrates this bug?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> Do you have a working recipe that demonstrates this bug?

Sorry; forgot that.  Use this simpler file instead:

------------8<------------------

;; runemacs.exe -Q --debug-init  -l "onetest.el" -f "1on1-emacs" "onetest.el"

(defun 1on1-emacs ()
  ""
  (interactive)
  (setq default-frame-alist
        (list
         '(font . "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1")
         '(bottom-divider-width . 2)
         '(minibuffer)))
  (setq pop-up-frames  t)
  (setq minibuffer-frame-alist (list '(height . 2)
                                     '(minibuffer . only))))
(global-set-key [C-S-mouse-1]
		(lambda () (interactive)
                  (message "FR: %S" (selected-frame))))

------------8<------------------

And I should have said that after step 3 use C-g
or whatever to end that step's M-x.  And select the
*scratch* frame.  IOW, step 4 is a repeat of step 3,
except that you do C-S-mouse-1 in the same frame,
*scratch*, not in another frame.

I just checked, and the same bug exists from Emacs
24.5 through 27.1.  IOW, it's still there.

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

[Eli Zaretskii]

> Date: Fri, 4 Dec 2020 09:43:47 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 17736@debbugs.gnu.org
> 
> ;; runemacs.exe -Q --debug-init  -l "onetest.el" -f "1on1-emacs" "onetest.el"
> 
> (defun 1on1-emacs ()
>   ""
>   (interactive)
>   (setq default-frame-alist
>         (list
>          '(font . "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1")
>          '(bottom-divider-width . 2)
>          '(minibuffer)))
>   (setq pop-up-frames  t)
>   (setq minibuffer-frame-alist (list '(height . 2)
>                                      '(minibuffer . only))))
> (global-set-key [C-S-mouse-1]
> 		(lambda () (interactive)
>                   (message "FR: %S" (selected-frame))))
> 
> ------------8<------------------
> 
> And I should have said that after step 3 use C-g
> or whatever to end that step's M-x.  And select the
> *scratch* frame.  IOW, step 4 is a repeat of step 3,
> except that you do C-S-mouse-1 in the same frame,
> *scratch*, not in another frame.
> 
> I just checked, and the same bug exists from Emacs
> 24.5 through 27.1.  IOW, it's still there.

Why is that a bug?  Clicking a mouse doesn't necessarily select the
frame where you click; if you want to know which frame you clocked on,
you should look at the click event.

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Sorry; forgot that.  Use this simpler file instead:
>
> ------------8<------------------
>
> ;; runemacs.exe -Q --debug-init  -l "onetest.el" -f "1on1-emacs" "onetest.el"
>
> (defun 1on1-emacs ()
>   ""
>   (interactive)
>   (setq default-frame-alist
>         (list
>          '(font . "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1")
>          '(bottom-divider-width . 2)
>          '(minibuffer)))
>   (setq pop-up-frames  t)
>   (setq minibuffer-frame-alist (list '(height . 2)
>                                      '(minibuffer . only))))

All that can't be necessary -- I don't have that font, so the example
still didn't work.

I removed the font setting, though, and tried to follow your recipe.

> (global-set-key [C-S-mouse-1]
> 		(lambda () (interactive)
>                   (message "FR: %S" (selected-frame))))
>
> ------------8<------------------
>
> And I should have said that after step 3 use C-g
> or whatever to end that step's M-x.  And select the
> *scratch* frame.  IOW, step 4 is a repeat of step 3,
> except that you do C-S-mouse-1 in the same frame,
> *scratch*, not in another frame.

And I was unable to, either because I don't understand the recipe, or
because the bugs isn't present in Emacs 28.

Could you provide a simpler step by step recipe to demonstrate the bug?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> I removed the font setting, though, 

Yes.

> and tried to follow your recipe.

> And I was unable to, either because I don't understand
> the recipe, or because the bugs isn't present in Emacs 28.
> 
> Could you provide a simpler step by step recipe to
> demonstrate the bug?

Could you say what you don't understand about the recipe?
Or could you explain what "I was unable to" amounts to?

Can you try with either the release for which the bug was
filed or other releases mentioned, which include Emacs 27?
There is no release Emacs 28, so I can't help you with that.

With Emacs 27.1, simply doing what I said shows the
reported behavior immediately, 100% of the time.

Here's the complete recipe again, in one place:

Command to start Emacs:

  z:\...\runemacs.exe -Q -l "onetest.el" -f "1on1-emacs"

File onetest.el contains this code:

(defun 1on1-emacs ()
  (interactive)
  (setq default-frame-alist
        (list '(bottom-divider-width . 2)
              '(minibuffer)))
  (setq pop-up-frames  t)
  (setq minibuffer-frame-alist (list '(height . 2)
                                     '(minibuffer . only))))
(global-set-key [C-S-mouse-1]
		(lambda () (interactive)
                  (message "FR: %S" (selected-frame))))

1. `C-x 5 o' to select frame *scratch*.
2. `C-x 5 2' to duplicate that frame.
3. `C-x b' to have that frame show *Messages*.
4. Resize the two non-minibuffer frames, so you
   can easily see all 3 frames completely.
5. Select the *scratch* frame (e.g. click mouse-1 there).
6. `C-S-mouse-1' in *scratch*.  See message in *Messages*
   saying that the selected frame is *scratch*.
7. Select *scratch* frame.  `C-S-mouse-1' in *Messages*.
   See message saying that selected frame is *Messages*.
8. Select *scratch* frame.  `M-x', then `C-S-mouse-1' in
   *Messages*.  See message: selected frame is *Messages*.
   `C-g' to cancel `M-x'.
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?  If so, we can talk about whether
#9 should be expected or is a bug.

It's possible that the behavior depends on the platform.
I'm using MS Windows (10).  It may well handle frame
focusing differently from some other platforms.

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> 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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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.

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

[Eli Zaretskii]

> Date: Mon, 7 Dec 2020 08:27:31 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 17736@debbugs.gnu.org
> 
> But THEN, if a user selects another frame

How did the user select that other frame in your recipe?