bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: luangruo@yahoo.com,  53170@debbugs.gnu.org
> Date: Tue, 11 Jan 2022 20:24:02 +0200
> 
> >>     (define-key keymap [mouse-2] 'Info-mouse-follow-link)
> >>     (define-key keymap [follow-link] 'mouse-face)
> >
> > Sorry, I don't understand how these settings explain the issue.
> > AFAIU, the 450 msec is the time one need to _hold_ mouse-1 to make
> > such a long mouse-1 press be considered as meaning "move point here".
> > By contrast, what happens here is that 2 separate mouse-1 clicks, if
> > the time between them is too short, seem to have no effect at all:
> > Emacs neither follows the link nor does anything else.
> >
> > So I suspect that something else is at work here, or maybe the effect
> > of mouse-1-click-follows-link is not documented accurately enough?
> >
> > Can you explain the observed behavior in more detail given the above
> > defaults, please?  In particular, how come a feature that's
> > documented to affect only "click and hold" mouse gestures seems to
> > affect double-click?
> 
> The second click selects the word.

Why is it useful to select the word on the header line?  It doesn't do
anything useful, AFAICT.

> Could you arrange the Info dir buffer such that clicking on a menu
> item opens another Info node, where the second quickly pressed mouse
> button is on another menu?  Then you will see the effect.  It
> selects the word on the menu item, instead of navigating to the node
> under the menu item.

Which means that the documentation of mouse-1-click-follows-link is
completely off target, because it says nothing about its effect on
double-click!

This is yet another bad UI change, whereby seemingly insignificant
random factors in what the user does cause very significant changes in
behavior.  In general, this should be unacceptable from the UX POV.
While it could be tolerated when the user needs to press a mouse
button continuously for almost 0.5 sec to have the "unusual" effect,
it is IMO completely unacceptable when a quick double-click sometimes
is processed as two single clicks, and causes Emacs to do nothing if
the time interval is short enough.

I think we should undo this "feature", at least in Info.