bug#66655: 29.1; Clicking buttons sometimes doesn't work

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: tomasralph2000@gmail.com,  66655@debbugs.gnu.org
> Date: Mon, 23 Oct 2023 12:38:35 -0400
> 
> > Stefan, I'd appreciate your review of the change, as this is a tricky
> > code, where we already had quite a few changes to avoid interpreting
> > an up-event as a drag event.
> 
> The change looks OK.  But yeah, it does feel like adding yet an
> other hack.  The whole:
> 
>                      /* Maybe the mouse has moved a lot, caused scrolling, and
>                         eventually ended up at the same screen position (but
>                         not buffer position) in which case it is a drag, not
>                         a click.  */
>                      /* FIXME: OTOH if the buffer position has changed
>                         because of a timer or process filter rather than
>                         because of mouse movement, it should be considered as
>                         a click.  But mouse-drag-region completely ignores
>                         this case and it hasn't caused any real problem, so
>                         it's probably OK to ignore it as well.  */
>                      && (EQ (Fcar (Fcdr (start_pos)),
>                              Fcar (Fcdr (position))) /* Same buffer pos */
>                          /* Redisplay hscrolled text between down- and
>                               up-events due to display-line-numbers-mode.  */
>                          || line_number_mode_hscroll (start_pos, position)
>                          || !EQ (Fcar (start_pos),
>                                  Fcar (position))))) /* Different window */
> 
> is unsatisfactory.  But it's not clear what is the right way to look at
> the problem.  As the comment says, we generally want "down+scroll+up" to
> be treated as a drag, but not in the current case.  I think the
> difference relies on what caused the scroll: if the scroll was the
> result of a deliberate act by the user (they moved the mouse after
> `down` to cause a scroll), then it's a drag and else it's not?

Yes, that's the logic here.  Technically, it happens because clicking
the mouse emits 2 events: down-mouse-1 followed by another one caused
by releasing the mouse button, and the first event could cause
redisplay (as happens in this case) because it generally moves point
to the location of the click.