GNU bug report logs - #47581
27.1; tab-bar missed mouse clicks on MS-Windows

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Ioannis Kappas <ioannis.kappas@HIDDEN>; dated Sat, 3 Apr 2021 11:21:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 47581 <at> debbugs.gnu.org:


Received: (at 47581) by debbugs.gnu.org; 4 Apr 2021 23:05:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 04 19:05:07 2021
Received: from localhost ([127.0.0.1]:36620 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lTBnm-0003WV-VO
	for submit <at> debbugs.gnu.org; Sun, 04 Apr 2021 19:05:07 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:31845)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1lTBnj-0003Vh-8t
 for 47581 <at> debbugs.gnu.org; Sun, 04 Apr 2021 19:05:05 -0400
X-Originating-IP: 91.129.107.223
Received: from mail.gandi.net (m91-129-107-223.cust.tele2.ee [91.129.107.223])
 (Authenticated sender: juri@HIDDEN)
 by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 68986240003;
 Sun,  4 Apr 2021 23:04:55 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows
Organization: LINKOV.NET
References: <CAMRHuGCz+X8VdUmNxJ4yMpVCFXB7Wq6xyZaSDXgvGUzBbS+9CA@HIDDEN>
 <CAMRHuGAbBDvkZQLyhFskULFS1a85=_85tbQ5STm7+Tkg0ChxQQ@HIDDEN>
 <83pmzbeajw.fsf@HIDDEN>
Date: Mon, 05 Apr 2021 02:00:47 +0300
In-Reply-To: <83pmzbeajw.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 03 Apr
 2021 16:56:35 +0300")
Message-ID: <87mtudac4g.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 47581
Cc: Ioannis Kappas <ioannis.kappas@HIDDEN>, 47581 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> I think the actual problem is elsewhere: in handle_tab_bar_click.  It
> includes code that was copied from handle_tool_bar_click, and which
> pays attention to the value of mouse-highlight.  But tab-bar buttons
> don't behave like tool-bar buttons in this regard: they don't respond
> to moving the mouse pointer to them by "activating" the button.  So I
> think that code should be removed from handle_tab_bar_click.  To wit:
> turn mouse-highlight off (M-x set-variable RET mouse-highlight RET nil
> RET), and clicks on tab-bar buttons miraculously start working with
> 100% reliability.
>
> Juri, why is that code present in handle_tab_bar_click?  Is that just
> a copy/paste from handle_tool_bar_click, or is there some reason for
> that?  I'm talking about this logic, and the comments which describe
> it, in handle_tab_bar_click:

Indeed, this code was copied from handle_tool_bar_click,
but this extra logic was not removed because there are parts
of the tab bar that should respond to moving the mouse pointer,
namely the tab close buttons are activated when the mouse pointer
is moved over them.  But I'm not sure if this feature is related
to this code, or won't be affected by removing this code.

>   /* If not on the highlighted tab-bar item, and mouse-highlight is
>      non-nil, return.  This is so we generate the tab-bar button
>      click only when the mouse button is released on the same item as
>      where it was pressed.  However, when mouse-highlight is disabled,
>      generate the click when the button is released regardless of the
>      highlight, since tab-bar items are not highlighted in that
>      case.  */
>   frame_to_window_pixel_xy (w, &x, &y);
>   ts = get_tab_bar_item (f, x, y, &glyph, &hpos, &vpos, &prop_idx, &close_p);
>   if (ts == -1
>       || (ts != 0 && !NILP (Vmouse_highlight)))
>     return;
>
>   /* When mouse-highlight is off, generate the click for the item
>      where the button was pressed, disregarding where it was
>      released.  */
>   if (NILP (Vmouse_highlight) && !down_p)
>     prop_idx = f->last_tab_bar_item;




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47581; Package emacs. Full text available.

Message received at 47581 <at> debbugs.gnu.org:


Received: (at 47581) by debbugs.gnu.org; 4 Apr 2021 19:49:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 04 15:49:44 2021
Received: from localhost ([127.0.0.1]:36499 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lT8kh-00010b-OT
	for submit <at> debbugs.gnu.org; Sun, 04 Apr 2021 15:49:44 -0400
Received: from mail-ot1-f53.google.com ([209.85.210.53]:37528)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ioannis.kappas@HIDDEN>) id 1lT8ke-00010N-Vd
 for 47581 <at> debbugs.gnu.org; Sun, 04 Apr 2021 15:49:41 -0400
Received: by mail-ot1-f53.google.com with SMTP id
 t23-20020a0568301e37b02901b65ab30024so9652109otr.4
 for <47581 <at> debbugs.gnu.org>; Sun, 04 Apr 2021 12:49:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=XLwzuhF1viqGYCSjEgxpBEMArDGKbfhe/tBvE0sv9gU=;
 b=UkNOkneoSHCWsKFV/+xMdauvYppdooCZzMYwWzCUeAFQNz9dILurbx6nnyYCCA5PWO
 YlcRC/3pzHLcs0L9fsHx96pZuEbXulaPqxKKHLZB0PdIcfh9E4tGadkW0rIMrMD8FLzv
 vkd/65rERHPl2ul7un6okEhhW8R5MX+/EtDmYNqw4B4rjzce0Z1H+Ml3Vr99p66w3lpu
 f4dxZqLgJbCXCZ6gPkbhYA+kise0CzATMjp2HQpjASzeyAwJKO+EufzuH77k31K8H7yK
 7HAP4DaCekxfKD4wh/ChvwVunAnG1NJChQVyAlB8bpaR1dDiE8SFiCYrMKVl83g/bOgc
 +xgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=XLwzuhF1viqGYCSjEgxpBEMArDGKbfhe/tBvE0sv9gU=;
 b=K/Kmp5V9OziJK3L6Hwvj8dtW8w8IWqZW71ltirZz5kmdAytnjqapsirMMzAumk2nGu
 q/UCjPRhHDpkFXH63TERMdD03RzqGCC/5Ol2ymnZRq+FWi30lWaf4hVbRqblpgpgub4y
 6E6fqgDOBxK2uhrMJASQwCJ5EYDUu/PmQjEjMK34q55nIwDvJPlOdCCVyAhOFCpuA5nD
 GjL5YXGzKE886l1qa1/3/ZRI66yKjAgjA4VnubTzX2pkdHXwbRliTbraQtraPy/NQ9iG
 z+TvbniQgcb/pprBdqEGrexiawBTXTMx3HWAu7YDgcuuLGpydrF8ZQTm+D0dRELNlAmP
 VrZA==
X-Gm-Message-State: AOAM532iHBvetMCx7mWZr85M20EY/Vv42Iz7ZsSXzzfNb1bfQq64AYtZ
 RthDhQ6tjcQpCKoGwFLrNvC8vNYuMF3Lt4JAJpI=
X-Google-Smtp-Source: ABdhPJxrx26uHWQ+A7usjbpumBqnrxugm+2viAIptKvQWnVQrHTVfvWWeh3AjZPo+3EPrXJEVcQ6tFIXFPdALBupNx0=
X-Received: by 2002:a9d:6e87:: with SMTP id a7mr19256213otr.298.1617565775061; 
 Sun, 04 Apr 2021 12:49:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAMRHuGCz+X8VdUmNxJ4yMpVCFXB7Wq6xyZaSDXgvGUzBbS+9CA@HIDDEN>
 <CAMRHuGAbBDvkZQLyhFskULFS1a85=_85tbQ5STm7+Tkg0ChxQQ@HIDDEN>
 <83pmzbeajw.fsf@HIDDEN>
 <CAMRHuGDyM+5V46=CeqCQmhU1TrNSbCerJ531zvPKiQ-Z=NN_fQ@HIDDEN>
In-Reply-To: <CAMRHuGDyM+5V46=CeqCQmhU1TrNSbCerJ531zvPKiQ-Z=NN_fQ@HIDDEN>
From: Ioannis Kappas <ioannis.kappas@HIDDEN>
Date: Sun, 4 Apr 2021 20:49:24 +0100
Message-ID: <CAMRHuGAzspP1LjvbwqX71SQnkpujBVz7OVFniSTXdVNZuGP3ag@HIDDEN>
Subject: Fwd: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000006c66e805bf2ae1af"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 47581
Cc: 47581 <at> debbugs.gnu.org, juri@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000006c66e805bf2ae1af
Content-Type: text/plain; charset="UTF-8"

Hi Eli,

On Sat, Apr 3, 2021 at 2:56 PM Eli Zaretskii <eliz@HIDDEN> wrote:

>
>
> Thanks, but this doesn't match my observations.
>
> First, I get a much smaller value for "virtual glyph" width: 5, not 9.
> (Did you look at the values in "emacs -Q" or in a session where fonts
> were customized?)
>

Indeed, the "Scale and Layout" on my monitor is set to 175% and thus
the difference. Setting it back to 100% gives a a virtual-glyph width
of 5px as per your correct observation with the following variable
glyph width sizes:

| column no.   |   1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 | 10 |
| glyph        | ?\s | ?* | ?s | ?c | ?r | ?a | ?t | ?c | ?h | ?* |
| width (px)   |   4 |  6 |  7 |  7 |  4 |  7 |  4 |  7 |  7 |  5 |
| end pos (px) |   4 | 10 | 17 | 24 | 28 | 35 | 39 | 46 | 53 | 58 |



>
> More importantly, remember_mouse_glyph is not called at all when I
> click on the tab-bar buttons, it is only called when I _move_ the
> mouse.  The decision whether we click on the same glyph or not is
> irrelevant to tab-bar buttons, it only cares if we click on the same
> _button_ as before, and that decision is made in get_tab_bar_item,
> which calls x_y_to_hpos_vpos, and the latter doesn't use any
> approximations of the glyph dimensions, it uses the actual pixel width
> of each glyph on display.
>

Agreed. Though, unless I am mistaken, it appears to me that the
virtual-glyph calculations performed during mouse moves over the
tab-bar, do indirectly affect the calculations during a mouse click.

I copied below a little sketch of how the situation appeared to me
while I was debugging the issue. During a mouse move, the A.1.1
predicate is referencing the virtual-glyph, fixed glyph size, calculation
from FRAME_DISPLAY_INFO's `last_mouse_glyph' done in A.1.1.2.1
and as thus it might not trigger A.1.1.1.1.1 to update MOUSE_HL_INFO when
the mouse moves to a different variable-sized glyph. The MOUSE_HL_INFO
value is later used during a mouse click in B.1.1.1 which, as a
consequence, might miss the tab activation (i.e. B.1.1.1.1 compares
the column returned from src/xdisp.c:x_y_to_hpos_vpos against a
potentially stale MOUSE_HL_INFO's mouse face beg/end col range):

A. src/w32term.c:w32_read_socket / (`WM_MOUSEMOVE' event)
   1. src/w32term.c:w32_note_mouse_movement
      1. Determine whether "Has the mouse moved off the glyph it was
         on at the last sighting?" by checking if the MOUSE_X and
         MOUSE_Y position fall outside the `RECT' of
         src/frame.h:FRAME_DISPLAY_INFO's `last_mouse_glyph'. If so
         1. src/xdisp.c:note_mouse_highlight
            1. src/xdisp.c:note_tab_bar_highlight
               1. sets src/frame.h:MOUSE_HL_INFO's
                  1. `mouse_face_beg_col' to the glyph column under the
mouse
                  2. `mouse_face_end_col' to the next glyph column under
the mouse
         2. Set src/w32term.h:FRAME_DISPLAY_INFO's `last_mouse_glyph'
            to the `RECT' that the glyph under the cursor occupies, by
            calling src/xdisp.c:remember_mouse_glyph:
            1. When it is over the tab-bar, it currently uses the
               `virtual_glyph' method to set RECT, which assumes all
               glyphs on the tab-bar row have a fixed width (sourced
               from src/frame.h:FRAME_SMALLEST_CHAR_WIDTH).
B. src/w32term.c:w32_read_socket / WM_*BUTTON* event
   1. src/w32term.c:w32_handle_tab_bar_click
      1. src/xdispl.c:handle_tab_bar_click
         1. src/xdispl.c:get_tab_bar_item
            1. Returns whether the mouse's X/Y is on the same item that
               was highlighted before. It does that by comparing, among
               other things, whether the column position HPOS returned by
               src/xdisp.c:x_y_to_hpos_vpos falls in the
               src/frame.h:MOUSE_HL_INFO's mouse face beg and end col range.
         2. if the above function indicates that the mouse cursor is
            on the same item that was highlighted before, then it
            activates the tab.


>
> I think the actual problem is elsewhere: in handle_tab_bar_click.  It
> includes code that was copied from handle_tool_bar_click, and which
> pays attention to the value of mouse-highlight.  But tab-bar buttons
> don't behave like tool-bar buttons in this regard: they don't respond
> to moving the mouse pointer to them by "activating" the button.  So I
> think that code should be removed from handle_tab_bar_click.  To wit:
> turn mouse-highlight off (M-x set-variable RET mouse-highlight RET nil
> RET), and clicks on tab-bar buttons miraculously start working with
> 100% reliability.
>

This will indeed also solve the problem by removing the comparison in
B.1.1 which is using the potentially stale
src/frame.h:MOUSE_HL_INFO, which to me seems to be the source of the
problem. And it is an even better solution, since that part of the
code might have been included there only by mistake. Nice catch!

Regardless of this though, assuming the above sketch is correct,
shouldn't we also consider fixing the code in
src/xdisp.c:remember_mouse_glyph so as to set the
src/w32term.h:FRAME_DISPLAY_INFO's `last_mouse_glyph' using
`text-glyph' coordinates, so as for A.1.1 to fire up based on the actual
tab-bar
glyph coordinates during a mouse move (so that MOUSE_HL_INFO does not
contain stale information)? I can't think of a reason why we might want
this to
be set using virtual-glyph coords when over the tab-bar (but then, I can
only see some of
the pieces and not the whole picture as you do).

Thanks!

--0000000000006c66e805bf2ae1af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr"><div dir=3D"lt=
r"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div=
 dir=3D"ltr"><div dir=3D"ltr"><div><font face=3D"monospace">Hi Eli,</font><=
/div><font face=3D"monospace"><br></font><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr"><font face=3D"monospace">On Sat, Apr 3, 2021=
 at 2:56 PM Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_bl=
ank">eliz@HIDDEN</a>&gt; wrote:<br></font></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><font face=3D"monospace"><br>
<br>
Thanks, but this doesn&#39;t match my observations.<br>
<br>
First, I get a much smaller value for &quot;virtual glyph&quot; width: 5, n=
ot 9.<br>
(Did you look at the values in &quot;emacs -Q&quot; or in a session where f=
onts<br>
were customized?)<br></font></blockquote><div><font face=3D"monospace"><br>=
</font></div><div><div><font face=3D"monospace">Indeed, the &quot;Scale and=
 Layout&quot; on my monitor is set to 175% and thus</font></div><div><font =
face=3D"monospace">the difference. Setting it back to 100% gives a a virtua=
l-glyph width</font></div><div><font face=3D"monospace">of 5px as per your =
correct observation with the following variable</font></div><div><font face=
=3D"monospace">glyph width sizes:</font></div><div><font face=3D"monospace"=
><br></font></div><div><font face=3D"monospace">| column no.=C2=A0 =C2=A0|=
=C2=A0 =C2=A01 |=C2=A0 2 |=C2=A0 3 |=C2=A0 4 |=C2=A0 5 |=C2=A0 6 |=C2=A0 7 =
|=C2=A0 8 |=C2=A0 9 | 10 |</font></div><div><font face=3D"monospace">| glyp=
h=C2=A0 =C2=A0 =C2=A0 =C2=A0 | ?\s | ?* | ?s | ?c | ?r | ?a | ?t | ?c | ?h =
| ?* |</font></div><div><font face=3D"monospace">| width (px)=C2=A0 =C2=A0|=
=C2=A0 =C2=A04 |=C2=A0 6 |=C2=A0 7 |=C2=A0 7 |=C2=A0 4 |=C2=A0 7 |=C2=A0 4 =
|=C2=A0 7 |=C2=A0 7 |=C2=A0 5 |</font></div><div><font face=3D"monospace">|=
 end pos (px) |=C2=A0 =C2=A04 | 10 | 17 | 24 | 28 | 35 | 39 | 46 | 53 | 58 =
|</font></div></div><div><br></div><div><font face=3D"monospace">=C2=A0</fo=
nt></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<font face=3D"monospace"><br>
More importantly, remember_mouse_glyph is not called at all when I<br>
click on the tab-bar buttons, it is only called when I _move_ the<br>
mouse.=C2=A0 The decision whether we click on the same glyph or not is<br>
irrelevant to tab-bar buttons, it only cares if we click on the same<br>
_button_ as before, and that decision is made in get_tab_bar_item,<br>
which calls x_y_to_hpos_vpos, and the latter doesn&#39;t use any<br>
approximations of the glyph dimensions, it uses the actual pixel width<br>
of each glyph on display.<br></font></blockquote><div><br></div><div><div><=
font face=3D"monospace">Agreed. Though, unless I am mistaken, it appears to=
 me that the</font></div><div><font face=3D"monospace">virtual-glyph calcul=
ations performed during mouse moves over the</font></div><div><font face=3D=
"monospace">tab-bar, do indirectly affect the calculations during a mouse c=
lick.</font></div><div><font face=3D"monospace"><br></font></div><div><font=
 face=3D"monospace">I copied below a little sketch of how the situation app=
eared to me</font></div><div><font face=3D"monospace">while I was debugging=
 the issue. During a mouse move, the A.1.1</font></div><div><font face=3D"m=
onospace">predicate is referencing the virtual-glyph, fixed glyph size, cal=
culation</font></div><div><font face=3D"monospace">from FRAME_DISPLAY_INFO&=
#39;s `last_mouse_glyph&#39; done in A.1.1.2.1</font></div><div><font face=
=3D"monospace"> and as thus=C2=A0it might not trigger A.1.1.1.1.1 to update=
 MOUSE_HL_INFO when=C2=A0</font></div><div><font face=3D"monospace">the mou=
se moves to a different variable-sized glyph. The MOUSE_HL_INFO</font></div=
><div><font face=3D"monospace">value is later used during a mouse click in =
B.1.1.1 which, as a</font></div><div><font face=3D"monospace">consequence, =
might miss the tab activation (i.e. B.1.1.1.1 compares</font></div><div><fo=
nt face=3D"monospace">the column returned from src/xdisp.c:x_y_to_hpos_vpos=
 against a</font></div><div><font face=3D"monospace">potentially stale MOUS=
E_HL_INFO&#39;s mouse face beg/end col range):</font></div><div><br></div><=
div><span style=3D"font-family:monospace">A. src/w32term.c:w32_read_socket =
/ (`WM_MOUSEMOVE&#39; event)</span><br></div><div><font face=3D"monospace">=
=C2=A0 =C2=A01. src/w32term.c:w32_note_mouse_movement</font></div><div><fon=
t face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 1. Determine whether &quot;Has th=
e mouse moved off the glyph it was</font></div><div><font face=3D"monospace=
">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on at the last sighting?&quot; by check=
ing if the MOUSE_X and</font></div><div><font face=3D"monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0MOUSE_Y position fall outside the `RECT&#39; of</fo=
nt></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sr=
c/frame.h:FRAME_DISPLAY_INFO&#39;s `last_mouse_glyph&#39;. If so</font></di=
v><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. src/xd=
isp.c:note_mouse_highlight</font></div><div><font face=3D"monospace">=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. src/xdisp.c:note_tab_bar_highlight</=
font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A01. sets src/frame.h:MOUSE_HL_INFO&#39;s</font></div><d=
iv><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 1. `mouse_face_beg_col&#39; to the glyph column under the=
 mouse</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. `mouse_face_end_col&#39; to the n=
ext glyph column under the mouse</font></div><div><font face=3D"monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. Set src/w32term.h:FRAME_DISPLAY_INFO&#=
39;s `last_mouse_glyph&#39;</font></div><div><font face=3D"monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to the `RECT&#39; that the glyph und=
er the cursor occupies, by</font></div><div><font face=3D"monospace">=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 calling src/xdisp.c:remember_mouse_glyp=
h:</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 1. When it is over the tab-bar, it currently uses the</font><=
/div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0`virtual_glyph&#39; method to set RECT, which assumes all<=
/font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0glyphs on the tab-bar row have a fixed width (sourc=
ed</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0from src/frame.h:FRAME_SMALLEST_CHAR_WIDTH).</fo=
nt></div><div><font face=3D"monospace">B. src/w32term.c:w32_read_socket / W=
M_*BUTTON* event</font></div><div><font face=3D"monospace">=C2=A0 =C2=A01. =
src/w32term.c:w32_handle_tab_bar_click</font></div><div><font face=3D"monos=
pace">=C2=A0 =C2=A0 =C2=A0 1. src/xdispl.c:handle_tab_bar_click</font></div=
><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. src/xdi=
spl.c:get_tab_bar_item</font></div><div><font face=3D"monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Returns whether the mouse&#39;s X/Y is o=
n the same item that</font></div><div><font face=3D"monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was highlighted before. It doe=
s that by comparing, among</font></div><div><font face=3D"monospace">=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other things, whether the =
column position HPOS returned by</font></div><div><font face=3D"monospace">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0src/xdisp.c:x_y_to_h=
pos_vpos falls in the</font></div><div><font face=3D"monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0src/frame.h:MOUSE_HL_INFO&#39;=
s mouse face beg and end col range.</font></div><div><font face=3D"monospac=
e">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. if the above function indicates tha=
t the mouse cursor is</font></div><div><font face=3D"monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on the same item that was highlighted befor=
e, then it</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 activates the tab.</font></div></div><div>=C2=A0<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><font face=3D"monospa=
ce">
<br>
I think the actual problem is elsewhere: in handle_tab_bar_click.=C2=A0 It<=
br>
includes code that was copied from handle_tool_bar_click, and which<br>
pays attention to the value of mouse-highlight.=C2=A0 But tab-bar buttons<b=
r>
don&#39;t behave like tool-bar buttons in this regard: they don&#39;t respo=
nd<br>
to moving the mouse pointer to them by &quot;activating&quot; the button.=
=C2=A0 So I<br>
think that code should be removed from handle_tab_bar_click.=C2=A0 To wit:<=
br>
turn mouse-highlight off (M-x set-variable RET mouse-highlight RET nil<br>
RET), and clicks on tab-bar buttons miraculously start working with<br>
100% reliability.<br></font></blockquote><div><br></div><div><font face=3D"=
monospace">This will indeed also solve the problem by removing the comparis=
on in</font></div><div><font face=3D"monospace">B.1.1 which is using the po=
tentially stale</font></div><div><font face=3D"monospace">src/frame.h:MOUSE=
_HL_INFO, which to me seems to be the source of the</font></div><div><font =
face=3D"monospace">problem. And it is an even better solution, since that p=
art of the</font></div><div><font face=3D"monospace">code might have been i=
ncluded there only by mistake. Nice catch!</font></div><div><font face=3D"m=
onospace"><br></font></div><div><font face=3D"monospace">Regardless of this=
 though, assuming the above sketch is correct,</font></div><div><font face=
=3D"monospace">shouldn&#39;t we also consider fixing the code in</font></di=
v><div><font face=3D"monospace">src/xdisp.c:remember_mouse_glyph so as to s=
et the</font></div><div><font face=3D"monospace">src/w32term.h:FRAME_DISPLA=
Y_INFO&#39;s `last_mouse_glyph&#39; using</font></div><div><font face=3D"mo=
nospace">`text-glyph&#39; coordinates, so as for A.1.1 to fire up based on =
the actual tab-bar</font></div><div><font face=3D"monospace">glyph coordina=
tes during a mouse move (so that MOUSE_HL_INFO does not</font></div><div><f=
ont face=3D"monospace">contain stale information)? I can&#39;t think of a r=
eason why we might want this to=C2=A0</font></div><div><font face=3D"monosp=
ace">be set using virtual-glyph coords when over the tab-bar (but then, I c=
an only see some of=C2=A0</font></div><div><font face=3D"monospace">the pie=
ces and not the whole picture as you do).</font></div><div><font face=3D"mo=
nospace">=C2=A0=C2=A0</font></div><div><font face=3D"monospace">Thanks!</fo=
nt></div></div></div></div></div></div></div></div></div></div>
</div></div>

--0000000000006c66e805bf2ae1af--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47581; Package emacs. Full text available.

Message received at 47581 <at> debbugs.gnu.org:


Received: (at 47581) by debbugs.gnu.org; 3 Apr 2021 13:56:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 03 09:56:57 2021
Received: from localhost ([127.0.0.1]:34273 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lSglk-0007QN-QD
	for submit <at> debbugs.gnu.org; Sat, 03 Apr 2021 09:56:57 -0400
Received: from eggs.gnu.org ([209.51.188.92]:54502)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1lSgli-0007QB-6j
 for 47581 <at> debbugs.gnu.org; Sat, 03 Apr 2021 09:56:55 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:53575)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1lSglc-0000CJ-AA; Sat, 03 Apr 2021 09:56:48 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2324
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1lSglb-0007Vy-Lz; Sat, 03 Apr 2021 09:56:48 -0400
Date: Sat, 03 Apr 2021 16:56:35 +0300
Message-Id: <83pmzbeajw.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Ioannis Kappas <ioannis.kappas@HIDDEN>, Juri Linkov <juri@HIDDEN>
In-Reply-To: <CAMRHuGAbBDvkZQLyhFskULFS1a85=_85tbQ5STm7+Tkg0ChxQQ@HIDDEN>
 (message from Ioannis Kappas on Sat, 3 Apr 2021 12:26:53 +0100)
Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows
References: <CAMRHuGCz+X8VdUmNxJ4yMpVCFXB7Wq6xyZaSDXgvGUzBbS+9CA@HIDDEN>
 <CAMRHuGAbBDvkZQLyhFskULFS1a85=_85tbQ5STm7+Tkg0ChxQQ@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 47581
Cc: 47581 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> From: Ioannis Kappas <ioannis.kappas@HIDDEN>
> Date: Sat, 3 Apr 2021 12:26:53 +0100
> 
> The issue appears to be due to the wrong calculation performed by the
> src/xdisp.c:remember_mouse_glyph fn to identify the RECTangle location
> of the glyph under the mouse cursor, when the mouse is over a tab.
> 
> The fn calls src/windows.c:window_from_coordinates to retrieve the
> window where the mouse is over, but this returns nil, resulting to a
> `virtual_glyph' position calculation, which appears to dictate that
> glyphs are fixed width having their width and height equal to the
> smallest char width and font height of the frame respectively.
> 
> But the tab bar glyphs are of variable size, and thus the glyph
> position rectangle returned by the above function will not necessarily
> correspond to the actual position of the glyph under the mouse cursor.
> 
> Consider the following example of glyph position in a tab-bar with a
> single *scratch* tab on MS-Windows. The src/xdisp.c:x_y_to_hpos_vpos
> fn used elsewhere in the tab logic correctly calculates the column
> HPOS as per below (e.g. the ?t glyph corresponds to column no. 7, it
> is 6px wide and occupies pixels 61 to 67 in the tab row):
> 
> | column no.   |   1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 |  10 |
> | glyph        | ?\s | ?* | ?s | ?c | ?r | ?a | ?t | ?c | ?h |  ?* |
> | width (px)   |   6 | 10 | 12 | 12 |  8 | 13 |  6 | 12 | 12 |   9 |
> | end pos (px) |   6 | 16 | 28 | 40 | 48 | 61 | 67 | 79 | 91 | 100 |
> 
> and the corresponding glyph positions returned by the
> src/xdisp.c:remember_mouse_glyph fn RECT on windows 10 (the fixed
> width of a glyph is 9px wide):
> 
> | column no.   |   1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 |  10 |
> | glyph        | ?\s | ?* | ?s | ?c | ?r | ?a | ?t | ?c | ?h |  ?* |
> | width (px)   |   9 |  9 |  9 |  9 |  9 |  9 |  9 |  9 |  9 |   9 |
> | end pos (px) |   9 | 18 | 27 | 36 | 45 | 54 | 63 | 82 | 91 | 100 |
> 
> The above miscalculation is used by
> src/w32term.c:w32_note_mouse_movement, to check if the mouse has moved
> over the last glyph and thus update the last glyph position
> accordingly. However, because the last glyph position check is based
> on the glyph coordinates performed by src/xdisp.c:remember_mouse_glyph
> `virtual_glyph' method, the glyph position does not correspond to the
> actual tab glyph, and updates can be missed.

Thanks, but this doesn't match my observations.

First, I get a much smaller value for "virtual glyph" width: 5, not 9.
(Did you look at the values in "emacs -Q" or in a session where fonts
were customized?)

More importantly, remember_mouse_glyph is not called at all when I
click on the tab-bar buttons, it is only called when I _move_ the
mouse.  The decision whether we click on the same glyph or not is
irrelevant to tab-bar buttons, it only cares if we click on the same
_button_ as before, and that decision is made in get_tab_bar_item,
which calls x_y_to_hpos_vpos, and the latter doesn't use any
approximations of the glyph dimensions, it uses the actual pixel width
of each glyph on display.

I think the actual problem is elsewhere: in handle_tab_bar_click.  It
includes code that was copied from handle_tool_bar_click, and which
pays attention to the value of mouse-highlight.  But tab-bar buttons
don't behave like tool-bar buttons in this regard: they don't respond
to moving the mouse pointer to them by "activating" the button.  So I
think that code should be removed from handle_tab_bar_click.  To wit:
turn mouse-highlight off (M-x set-variable RET mouse-highlight RET nil
RET), and clicks on tab-bar buttons miraculously start working with
100% reliability.

Juri, why is that code present in handle_tab_bar_click?  Is that just
a copy/paste from handle_tool_bar_click, or is there some reason for
that?  I'm talking about this logic, and the comments which describe
it, in handle_tab_bar_click:

  /* If not on the highlighted tab-bar item, and mouse-highlight is
     non-nil, return.  This is so we generate the tab-bar button
     click only when the mouse button is released on the same item as
     where it was pressed.  However, when mouse-highlight is disabled,
     generate the click when the button is released regardless of the
     highlight, since tab-bar items are not highlighted in that
     case.  */
  frame_to_window_pixel_xy (w, &x, &y);
  ts = get_tab_bar_item (f, x, y, &glyph, &hpos, &vpos, &prop_idx, &close_p);
  if (ts == -1
      || (ts != 0 && !NILP (Vmouse_highlight)))
    return;

  /* When mouse-highlight is off, generate the click for the item
     where the button was pressed, disregarding where it was
     released.  */
  if (NILP (Vmouse_highlight) && !down_p)
    prop_idx = f->last_tab_bar_item;




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47581; Package emacs. Full text available.

Message received at 47581 <at> debbugs.gnu.org:


Received: (at 47581) by debbugs.gnu.org; 3 Apr 2021 11:27:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 03 07:27:08 2021
Received: from localhost ([127.0.0.1]:33276 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lSeQl-0001QX-Pj
	for submit <at> debbugs.gnu.org; Sat, 03 Apr 2021 07:27:08 -0400
Received: from mail-oo1-f42.google.com ([209.85.161.42]:33436)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ioannis.kappas@HIDDEN>) id 1lSeQj-0001Q3-F5
 for 47581 <at> debbugs.gnu.org; Sat, 03 Apr 2021 07:27:06 -0400
Received: by mail-oo1-f42.google.com with SMTP id
 i25-20020a4aa1190000b02901bbd9429832so1847741ool.0
 for <47581 <at> debbugs.gnu.org>; Sat, 03 Apr 2021 04:27:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=2xOFtX0N1zuy3CSEICUVzDMYRnUdRefIJ4tOjiwvR54=;
 b=sEgp6KEguXu7XWlMfQPHJSTVrGZ5NkSJ0/NMlPrwCRJkCCKTJes6c0PXTpcQw/oppb
 XeIaOt1TW3Onn3WPaWhLlJ0aCTCx8QJStqAJzhAGmds7eQnhEordYfpoBNScM3bdxVis
 2HrusW7D4AhuvS+S2wOsF9f1y/gQSvZbi7OYo2ES8T30PoL6dFx575YIXzCsWenL7Rfn
 m0iv1VXf0MRQs36CLMRNGTskq71jy4UTqK8LrE7YM+f1Ke1Ccf8te+p0ward9lAWtL+S
 PhmnXMa8IQymLK3ki0Q2MqKc6eVT+84SRWNmuts+FznmfRdRCyRma2fRDP1cLRzWkNgY
 pG3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=2xOFtX0N1zuy3CSEICUVzDMYRnUdRefIJ4tOjiwvR54=;
 b=MRwGIj/FuMUFA9vL0kzZiAjbs8CZcNoGI7NQwzZNo1Qvt7J5h3sJkLljsFI5AIYeB7
 jSdUpbv7WPOh6b5ZXcw11+5sFkM5HyJGqoB4t4x7RXLYOvfyhwgZLgLU2g3KulUfY+Oo
 tPcsxuN6pTH/7ZpqgubIApijbpMImG9YjUaLLiG1O59jShJx2evkZCDCdTi4u1yE9PEn
 R+R3om0slfTcFWpjIzF1xDP5RJrqrJbJoUZG1WvsFkASQUkcWs50jsed7sMAfImlXfWR
 NhZqHXql7SlKngV6+UIf73UaBZTfU+96zO726Hni9Nfu80XQprtJPxjW4VuGriFxv00W
 j8bw==
X-Gm-Message-State: AOAM532jRkDxpI/M89AexR8CwnNyK/sl5fwsaC0/OQMFksP3pc0MpETM
 GrgIZMiaETq/Ks+2Ax91r7hsf3lESEOKPvV1Kn3Ajm8Y9i+qFw==
X-Google-Smtp-Source: ABdhPJyo2CMt1k+eHXIXotEcd7ulMbOKTgEGw0l87Asi5hydv/L6W6eadafzorIvgJtOVMdyyv3I2y+tb8D1Eg2tX1o=
X-Received: by 2002:a4a:ea11:: with SMTP id x17mr15165649ood.81.1617449219756; 
 Sat, 03 Apr 2021 04:26:59 -0700 (PDT)
MIME-Version: 1.0
From: Ioannis Kappas <ioannis.kappas@HIDDEN>
Date: Sat, 3 Apr 2021 12:26:53 +0100
Message-ID: <CAMRHuGAbBDvkZQLyhFskULFS1a85=_85tbQ5STm7+Tkg0ChxQQ@HIDDEN>
Subject: 27.1; tab-bar missed mouse clicks on MS-Windows
To: 47581 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="0000000000002f9a0b05bf0fbec8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47581
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000002f9a0b05bf0fbec8
Content-Type: text/plain; charset="UTF-8"

The issue appears to be due to the wrong calculation performed by the
src/xdisp.c:remember_mouse_glyph fn to identify the RECTangle location
of the glyph under the mouse cursor, when the mouse is over a tab.

The fn calls src/windows.c:window_from_coordinates to retrieve the
window where the mouse is over, but this returns nil, resulting to a
`virtual_glyph' position calculation, which appears to dictate that
glyphs are fixed width having their width and height equal to the
smallest char width and font height of the frame respectively.

But the tab bar glyphs are of variable size, and thus the glyph
position rectangle returned by the above function will not necessarily
correspond to the actual position of the glyph under the mouse cursor.

Consider the following example of glyph position in a tab-bar with a
single *scratch* tab on MS-Windows. The src/xdisp.c:x_y_to_hpos_vpos
fn used elsewhere in the tab logic correctly calculates the column
HPOS as per below (e.g. the ?t glyph corresponds to column no. 7, it
is 6px wide and occupies pixels 61 to 67 in the tab row):

| column no.   |   1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 |  10 |
| glyph        | ?\s | ?* | ?s | ?c | ?r | ?a | ?t | ?c | ?h |  ?* |
| width (px)   |   6 | 10 | 12 | 12 |  8 | 13 |  6 | 12 | 12 |   9 |
| end pos (px) |   6 | 16 | 28 | 40 | 48 | 61 | 67 | 79 | 91 | 100 |

and the corresponding glyph positions returned by the
src/xdisp.c:remember_mouse_glyph fn RECT on windows 10 (the fixed
width of a glyph is 9px wide):

| column no.   |   1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 |  10 |
| glyph        | ?\s | ?* | ?s | ?c | ?r | ?a | ?t | ?c | ?h |  ?* |
| width (px)   |   9 |  9 |  9 |  9 |  9 |  9 |  9 |  9 |  9 |   9 |
| end pos (px) |   9 | 18 | 27 | 36 | 45 | 54 | 63 | 82 | 91 | 100 |

The above miscalculation is used by
src/w32term.c:w32_note_mouse_movement, to check if the mouse has moved
over the last glyph and thus update the last glyph position
accordingly. However, because the last glyph position check is based
on the glyph coordinates performed by src/xdisp.c:remember_mouse_glyph
`virtual_glyph' method, the glyph position does not correspond to the
actual tab glyph, and updates can be missed.

Consider the following example. Mouse X coord is at position 62px,
both methodologies identify the mouse is over column 7; the mouse then
moves to X coord 60px i.e. the mouse is over the glyph at column 6,
but the `virtual_glyph' fixed width methodology thinks it is still on
column 7 (i.e. in 54-63), thus the update described earlier is missed,
resulting to a miss-activation of the tab as per this bug report.

Assuming the above analysis to be correct, there appears to be an easy
solution
(which seems rather to be a bug fix) to instruct
src/xdisp.c:remember_mouse_glyph
to call src/window.c:window_from_coordinates with a TAB_BAR_P argument of
true, thus letting it proceed with the correct RECT identification of
the glyph (the logic falls in the pseudo-window-p if block, and jumps
over to the `text_glyph' calculation):

diff --git a/src/xdisp.c b/src/xdisp.c
index 77c9af747c..c6d5f8b789 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -2609,7 +2609,7 @@ remember_mouse_glyph (struct frame *f, int gx, int
gy, NativeRectangle *rect)
       goto virtual_glyph;
     }
   else if (!f->glyphs_initialized_p
-    || (window = window_from_coordinates (f, gx, gy, &part, false, false),
+    || (window = window_from_coordinates (f, gx, gy, &part, true, false),
         NILP (window)))
     {
       width = FRAME_SMALLEST_CHAR_WIDTH (f);

Thanks

--0000000000002f9a0b05bf0fbec8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><font face=3D"monospace">The issue a=
ppears to be due to the wrong calculation performed by the</font></div><div=
><font face=3D"monospace">src/xdisp.c:remember_mouse_glyph fn to identify t=
he RECTangle location</font></div><div><font face=3D"monospace">of the glyp=
h under the mouse cursor, when the mouse is over a tab.</font></div><div><f=
ont face=3D"monospace"><br></font></div><div><font face=3D"monospace">The f=
n calls src/windows.c:window_from_coordinates to retrieve the</font></div><=
div><font face=3D"monospace">window where the mouse is over, but this retur=
ns nil, resulting to a</font></div><div><font face=3D"monospace">`virtual_g=
lyph&#39; position calculation, which appears to dictate that</font></div><=
div><font face=3D"monospace">glyphs are fixed width having their width and =
height equal to the</font></div><div><font face=3D"monospace">smallest char=
 width and font height of the frame respectively.</font></div><div><font fa=
ce=3D"monospace"><br></font></div><div><font face=3D"monospace">But the tab=
 bar glyphs are of variable size, and thus the glyph</font></div><div><font=
 face=3D"monospace">position rectangle returned by the above function will =
not necessarily</font></div><div><font face=3D"monospace">correspond to the=
 actual position of the glyph under the mouse cursor.</font></div><div><fon=
t face=3D"monospace"><br></font></div><div><font face=3D"monospace">Conside=
r the following example of glyph position in a tab-bar with a</font></div><=
div><font face=3D"monospace">single *scratch* tab on MS-Windows. The src/xd=
isp.c:x_y_to_hpos_vpos</font></div><div><font face=3D"monospace">fn used el=
sewhere in the tab logic correctly calculates the column</font></div><div><=
font face=3D"monospace">HPOS as per below (e.g. the ?t glyph corresponds to=
 column no. 7, it</font></div><div><font face=3D"monospace">is 6px wide and=
 occupies pixels 61 to 67 in the tab row):</font></div><div><font face=3D"m=
onospace"><br></font></div><div><font face=3D"monospace">| column no.=C2=A0=
 =C2=A0|=C2=A0 =C2=A01 |=C2=A0 2 |=C2=A0 3 |=C2=A0 4 |=C2=A0 5 |=C2=A0 6 |=
=C2=A0 7 |=C2=A0 8 |=C2=A0 9 |=C2=A0 10 |</font></div><div><font face=3D"mo=
nospace">| glyph=C2=A0 =C2=A0 =C2=A0 =C2=A0 | ?\s | ?* | ?s | ?c | ?r | ?a =
| ?t | ?c | ?h |=C2=A0 ?* |</font></div><div><font face=3D"monospace">| wid=
th (px)=C2=A0 =C2=A0|=C2=A0 =C2=A06 | 10 | 12 | 12 |=C2=A0 8 | 13 |=C2=A0 6=
 | 12 | 12 |=C2=A0 =C2=A09 |</font></div><div><font face=3D"monospace">| en=
d pos (px) |=C2=A0 =C2=A06 | 16 | 28 | 40 | 48 | 61 | 67 | 79 | 91 | 100 |<=
/font></div><div><font face=3D"monospace"><br></font></div><div><font face=
=3D"monospace">and the corresponding glyph positions returned by the</font>=
</div><div><font face=3D"monospace">src/xdisp.c:remember_mouse_glyph fn REC=
T on windows 10 (the fixed</font></div><div><font face=3D"monospace">width =
of a glyph is 9px wide):</font></div><div><font face=3D"monospace"><br></fo=
nt></div><div><font face=3D"monospace">| column no.=C2=A0 =C2=A0|=C2=A0 =C2=
=A01 |=C2=A0 2 |=C2=A0 3 |=C2=A0 4 |=C2=A0 5 |=C2=A0 6 |=C2=A0 7 |=C2=A0 8 =
|=C2=A0 9 |=C2=A0 10 |</font></div><div><font face=3D"monospace">| glyph=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 | ?\s | ?* | ?s | ?c | ?r | ?a | ?t | ?c | ?h |=C2=
=A0 ?* |</font></div><div><font face=3D"monospace">| width (px)=C2=A0 =C2=
=A0|=C2=A0 =C2=A09 |=C2=A0 9 |=C2=A0 9 |=C2=A0 9 |=C2=A0 9 |=C2=A0 9 |=C2=
=A0 9 |=C2=A0 9 |=C2=A0 9 |=C2=A0 =C2=A09 |</font></div><div><font face=3D"=
monospace">| end pos (px) |=C2=A0 =C2=A09 | 18 | 27 | 36 | 45 | 54 | 63 | 8=
2 | 91 | 100 |</font></div><div><font face=3D"monospace"><br></font></div><=
div><font face=3D"monospace">The above miscalculation is used by</font></di=
v><div><font face=3D"monospace">src/w32term.c:w32_note_mouse_movement, to c=
heck if the mouse has moved</font></div><div><font face=3D"monospace">over =
the last glyph and thus update the last glyph position</font></div><div><fo=
nt face=3D"monospace">accordingly. However, because the last glyph position=
 check is based</font></div><div><font face=3D"monospace">on the glyph coor=
dinates performed by src/xdisp.c:remember_mouse_glyph</font></div><div><fon=
t face=3D"monospace">`virtual_glyph&#39; method, the glyph position does no=
t correspond to the</font></div><div><font face=3D"monospace">actual tab gl=
yph, and updates can be missed.</font></div><div><font face=3D"monospace"><=
br></font></div><div><font face=3D"monospace">Consider the following exampl=
e. Mouse X coord is at position 62px,</font></div><div><font face=3D"monosp=
ace">both methodologies identify the mouse is over column 7; the mouse then=
</font></div><div><font face=3D"monospace">moves to X coord 60px i.e. the m=
ouse is over the glyph at column 6,</font></div><div><font face=3D"monospac=
e">but the `virtual_glyph&#39; fixed width methodology thinks it is still o=
n</font></div><div><font face=3D"monospace">column 7 (i.e. in 54-63), thus =
the update described earlier is missed,</font></div><div><font face=3D"mono=
space">resulting to a miss-activation of the tab as per this bug report.</f=
ont></div><div><font face=3D"monospace"><br></font></div><div><font face=3D=
"monospace">Assuming the above analysis to be correct, there appears to be =
an easy solution=C2=A0</font></div><div><font face=3D"monospace">(which see=
ms rather to be a bug=C2=A0</font><span style=3D"font-family:monospace">fix=
) to instruct src/xdisp.c:remember_mouse_glyph</span></div><div><span style=
=3D"font-family:monospace">to call=C2=A0</span><span style=3D"font-family:m=
onospace">src/window.c:window_from_coordinates with a TAB_BAR_P argument of=
</span></div><div><font face=3D"monospace">true, thus letting it proceed wi=
th the correct RECT identification of</font></div><div><font face=3D"monosp=
ace">the glyph (the logic falls in the pseudo-window-p if block, and jumps<=
/font></div><div><font face=3D"monospace">over to the `text_glyph&#39; calc=
ulation):</font></div><div><font face=3D"monospace"><br></font></div><div><=
font face=3D"monospace">diff --git a/src/xdisp.c b/src/xdisp.c</font></div>=
<div><font face=3D"monospace">index 77c9af747c..c6d5f8b789 100644</font></d=
iv><div><font face=3D"monospace">--- a/src/xdisp.c</font></div><div><font f=
ace=3D"monospace">+++ b/src/xdisp.c</font></div><div><font face=3D"monospac=
e">@@ -2609,7 +2609,7 @@ remember_mouse_glyph (struct frame *f, int gx, int=
 gy, NativeRectangle *rect)</font></div><div><font face=3D"monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0goto virtual_glyph;</font></div><div><font face=3D"=
monospace">=C2=A0 =C2=A0 =C2=A0}</font></div><div><font face=3D"monospace">=
=C2=A0 =C2=A0else if (!f-&gt;glyphs_initialized_p</font></div><div><font fa=
ce=3D"monospace">-<span style=3D"white-space:pre">	</span>=C2=A0 =C2=A0|| (=
window =3D window_from_coordinates (f, gx, gy, &amp;part, false, false),</f=
ont></div><div><font face=3D"monospace">+<span style=3D"white-space:pre">	<=
/span>=C2=A0 =C2=A0|| (window =3D window_from_coordinates (f, gx, gy, &amp;=
part, true, false),</font></div><div><font face=3D"monospace">=C2=A0<span s=
tyle=3D"white-space:pre">	</span>=C2=A0 =C2=A0 =C2=A0 =C2=A0NILP (window)))=
</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0{</font></di=
v><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0width =3D FRAME_=
SMALLEST_CHAR_WIDTH (f);</font></div><div><font face=3D"monospace"><br></fo=
nt></div><div><font face=3D"monospace">Thanks</font></div><div><br></div></=
div></div>

--0000000000002f9a0b05bf0fbec8--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#47581; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 3 Apr 2021 11:20:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 03 07:20:57 2021
Received: from localhost ([127.0.0.1]:33259 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lSeKm-0001Ga-TX
	for submit <at> debbugs.gnu.org; Sat, 03 Apr 2021 07:20:57 -0400
Received: from lists.gnu.org ([209.51.188.17]:39212)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ioannis.kappas@HIDDEN>) id 1lSeKg-0001GM-Oo
 for submit <at> debbugs.gnu.org; Sat, 03 Apr 2021 07:20:54 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:48306)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ioannis.kappas@HIDDEN>)
 id 1lSeKg-0008G5-JV
 for bug-gnu-emacs@HIDDEN; Sat, 03 Apr 2021 07:20:50 -0400
Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]:38450)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <ioannis.kappas@HIDDEN>)
 id 1lSeKa-0006xN-NG
 for bug-gnu-emacs@HIDDEN; Sat, 03 Apr 2021 07:20:50 -0400
Received: by mail-ot1-x332.google.com with SMTP id
 w21-20020a9d63950000b02901ce7b8c45b4so7083090otk.5
 for <bug-gnu-emacs@HIDDEN>; Sat, 03 Apr 2021 04:20:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=qK/AONd+FlavBbTJXTmzdvKu6baAX7NbLd4C5GxAgGc=;
 b=HNnJbJiAFCnZiyASRvsdlBeOJaoAAo5pSJRjvPIEkCx84XOdBBM1XYAU13WNA2sDF1
 pVA7JO8vj4h5GyQo6CxUzrskS4MFeUhpVrzvjvTC3pAardh3PehsOsoO6GlGtPImaWft
 s/nE27PjsNte2HqkJaXkpG22CM3eEra6XS8rhiN1A1WwMoPgNP9O1krkJAgfwccJ+bbi
 1EdakHQwvGo+sL269mVSevhTBc1N9OAifULaU/iLN0v9D3O0ndxcs0KgG6CQjYyUiE4k
 6l4Bo62FadQECvPxC7tJXsAEgUokKkphTArpkfUBK3A2E85/Syhn1iNN0GftPuGvDKz/
 ZG7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=qK/AONd+FlavBbTJXTmzdvKu6baAX7NbLd4C5GxAgGc=;
 b=WbVwKRgbuhQp8bP7DsNCWb2a50IiZ8rD7rJo3Adq4GNm5+QAXqzEYErf/4KvIpDo4F
 T/u5W5FDkZNwNr6Wrumi4dyx7o/jwB+7Vg+vBXFmpreo333swu+hGxr5Ai2zPjUO8l3T
 9loOuly4VBzLZZQ3X1vltkau5oU5ex248ZhNEtzgYkl8ycSvACTpA8i82NrgnSpuj+br
 G/ck3s316VV2p0JozjjGMtO0edtzN7RpAy+IgLcXir/zvS/KYtdg+gdubQJ2pSuQbLNn
 zyNjnzy3IVE80FtiL/V1eYU91pGn2BXcBLnzFPCPdSn9oXWdlHqDzMufCmCQCFi9M+sr
 ZdAQ==
X-Gm-Message-State: AOAM5313jX6fjMk8ohJTsEkrM7YPrS4PeRDdIi8ygwVPo3RuuyYc5h05
 CiUx1x81ECr0f6//MuLn3DfqO0ObqWX1j08zQYy09sFqUJtjfA==
X-Google-Smtp-Source: ABdhPJzU40EepAAFLKRM1gWwxtCj6il8vr0UgwOgzf8Qalpxp2TYOdsFfHJESTqBeKzc0iDMclXrdVyXITmmTFsM+TE=
X-Received: by 2002:a9d:5ef:: with SMTP id 102mr14824720otd.192.1617448842993; 
 Sat, 03 Apr 2021 04:20:42 -0700 (PDT)
MIME-Version: 1.0
From: Ioannis Kappas <ioannis.kappas@HIDDEN>
Date: Sat, 3 Apr 2021 12:20:36 +0100
Message-ID: <CAMRHuGCz+X8VdUmNxJ4yMpVCFXB7Wq6xyZaSDXgvGUzBbS+9CA@HIDDEN>
Subject: 27.1; tab-bar missed mouse clicks on MS-Windows
To: bug-gnu-emacs@HIDDEN
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2607:f8b0:4864:20::332;
 envelope-from=ioannis.kappas@HIDDEN; helo=mail-ot1-x332.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

There appears to be an issue with the tab bar on MS-Windows that
sometimes it does not register mouse clicks.

Steps to reproduce

1. Run emacs -Q.
2. M-x tab-bar-mode, the tab bar opens with a tab on the *scratch*
   buffer.
3. Press the + button on the tab bar, a second tab is created on the
   same buffer.
4. Keep switching between the two tabs using the mouse, you will
   notice that sometimes clicking on the inactive tab does not
   activate it as expected.

Analysis and likely solution to follow.

In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-11-19 built on fv-az68-340
Repository revision: ec297125a76481c55390d0b329e541907879d6f3
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10

Configured using:
 'configure --prefix=/mingw64 --build=x86_64-w64-mingw32 --with-modules
 --without-dbus --without-compress-install 'CFLAGS=-march=x86-64
 -mtune=generic -O2 -pipe' CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1
 'LDFLAGS=-pipe
 -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high''




Acknowledgement sent to Ioannis Kappas <ioannis.kappas@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#47581; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 4 Apr 2021 23:15:02 UTC

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