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

[Po Lu]

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.