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

[Stefan Monnier]

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


        Stefan