bug#48409: Text runs away before user can copy it

[Alan Mackenzie]

Hello, Eli.

On Tue, May 18, 2021 at 22:05:03 +0300, Eli Zaretskii wrote:
> > Date: Tue, 18 May 2021 18:42:16 +0000
> > Cc: Juri Linkov <juri@linkov.net>, 48409@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > How can a simple stationary click in the echo area become a drag event?
> > I'm guessing there's some subtle bug in some function such as
> > make_lispy_event in keyboard.c.  Any mouse experts who have suggestions,
> > please chime in, here!

> I think this is explained at the end of the node "Drag Events" in the
> ELisp manual.

Erm, not really.  That bit explains how a drag event can become a click
event, not the other way around.  Thanks anyhow.

I think I know why the problem is happening.  When there are two lines
of text in the miniwindow:
(i) A down-mouse event occurs in the miniwindow:
  o - the mouse position relative to the top of the two-line miniwindow
    is stored somewhere.
  o - redisplay (or something) changes the two-line miniwindow into a
    one-line miniwindow.
(ii) The up-mouse event occurs in the same place:
  o - the mouse position is determined  RELATIVE TO THE NEWLY SIZED
    MINIWINDOW.
  o - The y coordinate is significantly different from that of the
    stored mouse position.
  o - Due to this difference, make_lispy_event thinks the mouse has
    moved, so returns a drag event.

The above is the basic scenario.  If the mouse is on the top line of the
miniwindow when the mouse is clicked, the returned y coordinate at (ii)
is in the mode line of the window above, and is determined relative to
that window.

I don't have any workable ideas on how to fix this bug.  The only idea
which springs to mind is to move from expressing mouse positions
relative to a window to expressing it relative to a frame.  Or, maybe
the resizing of the miniwindow could be postponed till after the
up-mouse event.

Who is the mouse expert in Emacs?  What does he say?

-- 
Alan Mackenzie (Nuremberg, Germany).