GNU bug report logs - #53170
29.0.50; Can't repetitively click next node button inside Info header line

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53170 in the body.
You can then email your comments to 53170 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Can't repetitively click next node button inside Info
 header line
Date: Tue, 11 Jan 2022 10:16:12 +0800

Starting from emacs -Q, say "C-h i m tramp RET", then click the text
that reads "Next: Overview".  As long as you don't move the mouse at
all, you won't be able to click that button again.

Thanks.

In GNU Emacs 29.0.50 (build 304, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2022-01-11 built on trinity
Repository revision: c060e374a15b54ce7861896602961330f9aa58c6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Fedora Linux 35 (Workstation Edition)

Configured using:
 'configure --cache-file=/tmp/ccache --with-xinput2 --with-xwidgets'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11
XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr mule-util info emacsbug message mailcap
yank-media rmc puny dired dired-loaddefs rfc822 mml mml-sec
password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date seq gv subr-x byte-opt bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils iso-transl tooltip
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget keymap hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 50917 11883)
 (symbols 48 6021 1)
 (strings 32 19743 2081)
 (string-bytes 1 738691)
 (vectors 16 11509)
 (vector-slots 8 165885 14569)
 (floats 8 23 49)
 (intervals 56 569 129)
 (buffers 992 11))

Message #8 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50; Can't repetitively click next node button
 inside Info header line
Date: Tue, 11 Jan 2022 11:01:53 +0200

> Starting from emacs -Q, say "C-h i m tramp RET", then click the text
> that reads "Next: Overview".  As long as you don't move the mouse at
> all, you won't be able to click that button again.

I guess this is the case when you click the mouse button too fast?
By default, mouse-1-click-follows-link is 450, and Info-link-keymap
uses such settings:

    (define-key keymap [mouse-2] 'Info-mouse-follow-link)
    (define-key keymap [follow-link] 'mouse-face)

Message #13 received at 53170-done <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 53170-done <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50; Can't repetitively click next node button
 inside Info header line
Date: Tue, 11 Jan 2022 17:40:55 +0800

Juri Linkov <juri <at> linkov.net> writes:

> I guess this is the case when you click the mouse button too fast?
> By default, mouse-1-click-follows-link is 450, and Info-link-keymap
> uses such settings:

>     (define-key keymap [mouse-2] 'Info-mouse-follow-link)
>     (define-key keymap [follow-link] 'mouse-face)

Hmm, that seems to be the case indeed.
I'm closing this bug, thanks.

Message #16 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: luangruo <at> yahoo.com, 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50;
 Can't repetitively click next node button inside Info header line
Date: Tue, 11 Jan 2022 15:26:17 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Date: Tue, 11 Jan 2022 11:01:53 +0200
> Cc: 53170 <at> debbugs.gnu.org
> 
> > Starting from emacs -Q, say "C-h i m tramp RET", then click the text
> > that reads "Next: Overview".  As long as you don't move the mouse at
> > all, you won't be able to click that button again.
> 
> I guess this is the case when you click the mouse button too fast?
> By default, mouse-1-click-follows-link is 450, and Info-link-keymap
> uses such settings:
> 
>     (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?

Message #19 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50; Can't repetitively click next node button
 inside Info header line
Date: Tue, 11 Jan 2022 20:24:02 +0200

>> > Starting from emacs -Q, say "C-h i m tramp RET", then click the text
>> > that reads "Next: Overview".  As long as you don't move the mouse at
>> > all, you won't be able to click that button again.
>> 
>> I guess this is the case when you click the mouse button too fast?
>> By default, mouse-1-click-follows-link is 450, and Info-link-keymap
>> uses such settings:
>> 
>>     (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.  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.

Message #22 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: luangruo <at> yahoo.com, 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50; Can't repetitively click next node button
 inside Info header line
Date: Tue, 11 Jan 2022 20:55:29 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: luangruo <at> yahoo.com,  53170 <at> 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.

Message #25 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50; Can't repetitively click next node button
 inside Info header line
Date: Tue, 11 Jan 2022 21:12:50 +0200

>> The second click selects the word.
>
> Why is it useful to select the word on the header line?

Sorry, I missed that this report is about the header line,
I thought it's about breadcrumbs.

Then these bindings are interfering:

    (define-key keymap [header-line down-mouse-1] 'mouse-drag-header-line)
    (define-key keymap [header-line mouse-1] 'mouse-select-window)

The problem can be fixed by replacing these lines with:

    (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)

But I don't know how important is the feature of selecting/dragging the header-line?

Message #28 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: luangruo <at> yahoo.com, 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50; Can't repetitively click next node button
 inside Info header line
Date: Tue, 11 Jan 2022 22:03:07 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: luangruo <at> yahoo.com,  53170 <at> debbugs.gnu.org
> Date: Tue, 11 Jan 2022 21:12:50 +0200
> 
> >> The second click selects the word.
> >
> > Why is it useful to select the word on the header line?
> 
> Sorry, I missed that this report is about the header line,
> I thought it's about breadcrumbs.
> 
> Then these bindings are interfering:
> 
>     (define-key keymap [header-line down-mouse-1] 'mouse-drag-header-line)
>     (define-key keymap [header-line mouse-1] 'mouse-select-window)
> 
> The problem can be fixed by replacing these lines with:
> 
>     (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)
> 
> But I don't know how important is the feature of selecting/dragging the header-line?

I don't think I understand how 2 clicks one after another are taken as
a drag-mouse event.  Can you tell why this happens?

Message #31 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50; Can't repetitively click next node button
 inside Info header line
Date: Wed, 12 Jan 2022 19:20:40 +0200

>> Then these bindings are interfering:
>>
>>     (define-key keymap [header-line down-mouse-1] 'mouse-drag-header-line)
>>     (define-key keymap [header-line mouse-1] 'mouse-select-window)
>>
>> The problem can be fixed by replacing these lines with:
>>
>>     (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)
>>
>> But I don't know how important is the feature of selecting/dragging the header-line?
>
> I don't think I understand how 2 clicks one after another are taken as
> a drag-mouse event.  Can you tell why this happens?

Actually, its's mouse-select-window that steals the click.
There is no need to bind mouse-1 to mouse-select-window
because the window is selected anyway, so this patch fixes
the reported problem:

diff --git a/lisp/info.el b/lisp/info.el
index f4f0f9790c..bb8cd0d312 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -4693,7 +4693,7 @@ Info-goto-emacs-key-command-node
 (defvar Info-link-keymap
   (let ((keymap (make-sparse-keymap)))
     (define-key keymap [header-line down-mouse-1] 'mouse-drag-header-line)
-    (define-key keymap [header-line mouse-1] 'mouse-select-window)
+    (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)
     (define-key keymap [header-line mouse-2] 'Info-mouse-follow-link)
     (define-key keymap [mouse-2] 'Info-mouse-follow-link)
     (define-key keymap [follow-link] 'mouse-face)
-- 

Message #34 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: luangruo <at> yahoo.com, 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50; Can't repetitively click next node button
 inside Info header line
Date: Wed, 12 Jan 2022 19:29:54 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: luangruo <at> yahoo.com,  53170 <at> debbugs.gnu.org
> Date: Wed, 12 Jan 2022 19:20:40 +0200
> 
> >> But I don't know how important is the feature of selecting/dragging the header-line?
> >
> > I don't think I understand how 2 clicks one after another are taken as
> > a drag-mouse event.  Can you tell why this happens?
> 
> Actually, its's mouse-select-window that steals the click.
> There is no need to bind mouse-1 to mouse-select-window
> because the window is selected anyway, so this patch fixes
> the reported problem:

Thanks, this LGTM.

Message #37 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50; Can't repetitively click next node button
 inside Info header line
Date: Mon, 24 Jan 2022 20:56:40 +0200

>> >> But I don't know how important is the feature of selecting/dragging the header-line?
>> >
>> > I don't think I understand how 2 clicks one after another are taken as
>> > a drag-mouse event.  Can you tell why this happens?
>> 
>> Actually, its's mouse-select-window that steals the click.
>> There is no need to bind mouse-1 to mouse-select-window
>> because the window is selected anyway, so this patch fixes
>> the reported problem:
>
> Thanks, this LGTM.

So now pushed to master.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.