bug#51246: 29.0.50; New tab button on tab bar doesn't respond to button up events

bug#51246: 29.0.50; New tab button on tab bar doesn't respond to button up events

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

In Emacs 27, and Emacs 28 up until a certain point, clicking the "+"
button in the tab bar would respond in two steps; When the mouse button
was pressed, the button would display in a depressed appearance, and
only when the button was released would a new tab actually be created.

This is the typical behaviour of X-Windows applications that have tab
bars, and provides visual feedback to the user that a new tab is about
to created, giving the user an opportunity to cancel the action if the
click was inadvertent.

In master and emacs-28, clicking "new tab" results in a new tab being
created immediately when the mouse button is pressed, without waiting
for it to be released.  This behaviour is very annoying!

In GNU Emacs 29.0.50 (build 191, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-10-17 built on limity
Repository revision: 3a283bf727f5adb494689315c9e89483525402e3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101002
System Description: Fedora 34 (Workstation Edition)

Configured using:
 'configure'

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 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  tab-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map 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 hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 53013 10603)
 (symbols 48 6630 1)
 (strings 32 20210 1924)
 (string-bytes 1 667135)
 (vectors 16 13769)
 (vector-slots 8 185208 14800)
 (floats 8 21 39)
 (intervals 56 214 4)
 (buffers 992 10))

bug#51246: 29.0.50; New tab button on tab bar doesn't respond to button up events

[Eli Zaretskii]

> Date: Sun, 17 Oct 2021 11:11:39 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> In master and emacs-28, clicking "new tab" results in a new tab being
> created immediately when the mouse button is pressed, without waiting
> for it to be released.  This behaviour is very annoying!

Please explain why it's annoying, and why you cannot solve your
annoyance by rebinding the relevant commands to the mouse gestures
which you find less annoying.

Thanks.

bug#51246: 29.0.50; New tab button on tab bar doesn't respond to button up events

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> In master and emacs-28, clicking "new tab" results in a new tab being
>> created immediately when the mouse button is pressed, without waiting
>> for it to be released.  This behaviour is very annoying!

> Please explain why it's annoying, and why you cannot solve your
> annoyance by rebinding the relevant commands to the mouse gestures
> which you find less annoying.

It's annoying because there is absolutely no feedback between when the
mouse clicks down on the button, and when the new tab is created, much
less an opportunity for the user to cancel the action.

For instance, it is easy to accidentally click the "new tab" button when
selecting "Open File" in the toolbar on GTK+ builds.  When this happens
in 27.2, the user can simply move the mouse outside the button before
releasing the mouse button, which cancels the action.  (This is also
consistent with every other X-Windows application.)  However, in Emacs
28, the user will have to find the new tab that was inadvertently
created and close it, which takes longer and is surprising, because it
is inconsistent with all other X-Windows applications.

Rebinding the "new tab" command to tab-bar mouse-1 (instead of
down-mouse-1, which is what it seems to be right now) would certainly be
possible, but I don't understand how the tab bar code works: when I run
describe-key and click the "+" button, I'm told tab-bar mouse-1 is bound
to `tab-bar-close-tab-from-button', and tab-bar down-mouse-1 is bound to
`tab-bar-mouse-select-tab', neither of which make much sense, because
the "+" button creates a new tab, not select or close an existing one.

Could someone explain exactly which command runs when the "+" button is
clicked, and how to bind it to mouse-1, instead of down-mouse-1?

Either way, the old behaviour should be the default; it would be nice to
have it restored, and I'd be happy to help with restoring it if
possible.

Thanks.

bug#51246: 29.0.50; New tab button on tab bar doesn't respond to button up events

[Juri Linkov]

close 51246 28.0.60
thanks

> It's annoying because there is absolutely no feedback between when the
> mouse clicks down on the button, and when the new tab is created, much
> less an opportunity for the user to cancel the action.

I agree, and web browsers also implement this as you described.
It was just an oversight, not a design decision, so I fixed this now.
Thanks for noticing.

> Rebinding the "new tab" command to tab-bar mouse-1 (instead of
> down-mouse-1, which is what it seems to be right now) would certainly be
> possible, but I don't understand how the tab bar code works: when I run
> describe-key and click the "+" button, I'm told tab-bar mouse-1 is bound
> to `tab-bar-close-tab-from-button', and tab-bar down-mouse-1 is bound to
> `tab-bar-mouse-select-tab', neither of which make much sense, because
> the "+" button creates a new tab, not select or close an existing one.

You are right, these names make no sense, so I renamed them now.

> Could someone explain exactly which command runs when the "+" button is
> clicked, and how to bind it to mouse-1, instead of down-mouse-1?

There bindings are applied to the whole tab bar, not to each tab.
This is in contrast to how the tab line is implemented
where it's possible to bind different keys to each tab.