From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ioannis Kappas Newsgroups: gmane.emacs.bugs Subject: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows Date: Sat, 3 Apr 2021 12:26:53 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002f9a0b05bf0fbec8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21900"; mail-complaints-to="usenet@ciao.gmane.io" To: 47581@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 03 13:28:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lSeRm-0005XZ-Qn for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 03 Apr 2021 13:28:10 +0200 Original-Received: from localhost ([::1]:43366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lSeRl-0002Y0-Rg for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 03 Apr 2021 07:28:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49728) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lSeRe-0002Xu-6g for bug-gnu-emacs@gnu.org; Sat, 03 Apr 2021 07:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49963) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lSeRd-00034Y-Nq for bug-gnu-emacs@gnu.org; Sat, 03 Apr 2021 07:28:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lSeRd-0001Ro-KC for bug-gnu-emacs@gnu.org; Sat, 03 Apr 2021 07:28:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Ioannis Kappas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Apr 2021 11:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47581 X-GNU-PR-Package: emacs Original-Received: via spool by 47581-submit@debbugs.gnu.org id=B47581.16174492285494 (code B ref 47581); Sat, 03 Apr 2021 11:28:01 +0000 Original-Received: (at 47581) by debbugs.gnu.org; 3 Apr 2021 11:27:08 +0000 Original-Received: from localhost ([127.0.0.1]:33276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lSeQl-0001QX-Pj for submit@debbugs.gnu.org; Sat, 03 Apr 2021 07:27:08 -0400 Original-Received: from mail-oo1-f42.google.com ([209.85.161.42]:33436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lSeQj-0001Q3-F5 for 47581@debbugs.gnu.org; Sat, 03 Apr 2021 07:27:06 -0400 Original-Received: by mail-oo1-f42.google.com with SMTP id i25-20020a4aa1190000b02901bbd9429832so1847741ool.0 for <47581@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) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:203489 Archived-At: --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
The issue a= ppears to be due to the wrong calculation performed by the
src/xdisp.c:remember_mouse_glyph fn to identify t= he RECTangle location
of the glyp= h under the mouse cursor, when the mouse is over a tab.

The f= n calls src/windows.c:window_from_coordinates to retrieve the
<= div>window where the mouse is over, but this retur= ns nil, resulting to a
`virtual_g= lyph' position calculation, which appears to dictate that
<= div>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.

Conside= r the following example of glyph position in a tab-bar with a
<= div>single *scratch* tab on MS-Windows. The src/xd= isp.c:x_y_to_hpos_vpos
fn used el= sewhere in the tab logic correctly calculates the column
<= font face=3D"monospace">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.=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 |
| glyph=C2=A0 =C2=A0 =C2=A0 =C2=A0 | ?\s | ?* | ?s | ?c | ?r | ?a = | ?t | ?c | ?h |=C2=A0 ?* |
| 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 |
| en= d pos (px) |=C2=A0 =C2=A06 | 16 | 28 | 40 | 48 | 61 | 67 | 79 | 91 | 100 |<= /font>

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

| 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 |
| glyph=C2= =A0 =C2=A0 =C2=A0 =C2=A0 | ?\s | ?* | ?s | ?c | ?r | ?a | ?t | ?c | ?h |=C2= =A0 ?* |
| 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 |
| end pos (px) |=C2=A0 =C2=A09 | 18 | 27 | 36 | 45 | 54 | 63 | 8= 2 | 91 | 100 |

<= div>The above miscalculation is used by
src/w32term.c:w32_note_mouse_movement, to c= heck 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 coor= dinates performed by src/xdisp.c:remember_mouse_glyph
`virtual_glyph' method, the glyph position does no= t correspond to the
actual tab gl= yph, and updates can be missed.
<= br>
Consider the following exampl= e. 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 m= ouse is over the glyph at column 6,
but the `virtual_glyph' fixed width methodology thinks it is still o= n
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=C2=A0
(which see= ms rather to be a bug=C2=A0fix= ) to instruct src/xdisp.c:remember_mouse_glyph
to call=C2=A0src/window.c:window_from_coordinates with a TAB_BAR_P argument of=
true, thus letting it proceed wi= th the correct RECT identification of
the glyph (the logic falls in the pseudo-window-p if block, and jumps<= /font>
over to the `text_glyph' calc= ulation):

<= font face=3D"monospace">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)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0goto virtual_glyph;
=C2=A0 =C2=A0 =C2=A0}
= =C2=A0 =C2=A0else if (!f->glyphs_initialized_p
- =C2=A0 =C2=A0|| (= window =3D window_from_coordinates (f, gx, gy, &part, false, false),
+ <= /span>=C2=A0 =C2=A0|| (window =3D window_from_coordinates (f, gx, gy, &= part, true, false),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NILP (window)))=
=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0width =3D FRAME_= SMALLEST_CHAR_WIDTH (f);

Thanks

--0000000000002f9a0b05bf0fbec8--