From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 03 07:20:57 2021 Received: (at submit) by debbugs.gnu.org; 3 Apr 2021 11:20:57 +0000 Received: from localhost ([127.0.0.1]:33259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lSeKm-0001Ga-TX for submit@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 ) id 1lSeKg-0001GM-Oo for submit@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 ) id 1lSeKg-0008G5-JV for bug-gnu-emacs@gnu.org; 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 ) id 1lSeKa-0006xN-NG for bug-gnu-emacs@gnu.org; Sat, 03 Apr 2021 07:20:50 -0400 Received: by mail-ot1-x332.google.com with SMTP id w21-20020a9d63950000b02901ce7b8c45b4so7083090otk.5 for ; 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 Date: Sat, 3 Apr 2021 12:20:36 +0100 Message-ID: Subject: 27.1; tab-bar missed mouse clicks on MS-Windows To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::332; envelope-from=ioannis.kappas@gmail.com; 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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'' From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 03 07:27:08 2021 Received: (at 47581) by debbugs.gnu.org; 3 Apr 2021 11:27:08 +0000 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 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 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) MIME-Version: 1.0 From: Ioannis Kappas Date: Sat, 3 Apr 2021 12:26:53 +0100 Message-ID: Subject: 27.1; tab-bar missed mouse clicks on MS-Windows To: 47581@debbugs.gnu.org Content-Type: multipart/alternative; boundary="0000000000002f9a0b05bf0fbec8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47581 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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
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-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 03 09:56:57 2021 Received: (at 47581) by debbugs.gnu.org; 3 Apr 2021 13:56:57 +0000 Received: from localhost ([127.0.0.1]:34273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lSglk-0007QN-QD for submit@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 ) id 1lSgli-0007QB-6j for 47581@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Ioannis Kappas , Juri Linkov In-Reply-To: (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: X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47581 Cc: 47581@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Ioannis Kappas > 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; From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 04 15:49:44 2021 Received: (at 47581) by debbugs.gnu.org; 4 Apr 2021 19:49:44 +0000 Received: from localhost ([127.0.0.1]:36499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lT8kh-00010b-OT for submit@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 ) id 1lT8ke-00010N-Vd for 47581@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@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: <83pmzbeajw.fsf@gnu.org> In-Reply-To: From: Ioannis Kappas Date: Sun, 4 Apr 2021 20:49:24 +0100 Message-ID: Subject: Fwd: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000006c66e805bf2ae1af" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47581 Cc: 47581@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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
Hi Eli,<= /div>
On Sat, Apr 3, 2021= at 2:56 PM Eli Zaretskii <eliz@gnu.org> wrote:


Thanks, but this doesn't match my observations.

First, I get a much smaller value for "virtual glyph" width: 5, n= ot 9.
(Did you look at the values in "emacs -Q" or in a session where f= onts
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 virtua= l-glyph width
of 5px as per your = correct observation with the following variable
glyph width sizes:

| 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 |
| glyp= h=C2=A0 =C2=A0 =C2=A0 =C2=A0 | ?\s | ?* | ?s | ?c | ?r | ?a | ?t | ?c | ?h = | ?* |
| 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 |
|= end pos (px) |=C2=A0 =C2=A04 | 10 | 17 | 24 | 28 | 35 | 39 | 46 | 53 | 58 = |

=C2=A0

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.=C2=A0 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.

<= font face=3D"monospace">Agreed. Though, unless I am mistaken, it appears to= me that the
virtual-glyph calcul= ations performed during mouse moves over the
tab-bar, do indirectly affect the calculations during a mouse c= lick.

I copied below a little sketch of how the situation app= eared 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, cal= culation
from FRAME_DISPLAY_INFO&= #39;s `last_mouse_glyph' done in A.1.1.2.1
and as thus=C2=A0it might not trigger A.1.1.1.1.1 to update= MOUSE_HL_INFO when=C2=A0
the mou= se 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 MOUS= E_HL_INFO's mouse face beg/end col range):

<= div>A. src/w32term.c:w32_read_socket = / (`WM_MOUSEMOVE' event)
= =C2=A0 =C2=A01. src/w32term.c:w32_note_mouse_movement
=C2=A0 =C2=A0 =C2=A0 1. Determine whether "Has th= e mouse moved off the glyph it was
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on at the last sighting?" by check= ing if the MOUSE_X and
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0MOUSE_Y position fall outside the `RECT' of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sr= c/frame.h:FRAME_DISPLAY_INFO's `last_mouse_glyph'. If so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. src/xd= isp.c:note_mouse_highlight
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. src/xdisp.c:note_tab_bar_highlight
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A01. sets src/frame.h:MOUSE_HL_INFO's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 1. `mouse_face_beg_col' to the glyph column under the= mouse
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. `mouse_face_end_col' to the n= ext glyph column under the mouse
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. Set src/w32term.h:FRAME_DISPLAY_INFO&#= 39;s `last_mouse_glyph'
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to the `RECT' that the glyph und= er the cursor occupies, by
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 calling src/xdisp.c:remember_mouse_glyp= h:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 1. When it is over the tab-bar, it currently uses the<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0`virtual_glyph' method to set RECT, which assumes all<= /font>
=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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0from src/frame.h:FRAME_SMALLEST_CHAR_WIDTH).
B. src/w32term.c:w32_read_socket / W= M_*BUTTON* event
=C2=A0 =C2=A01. = src/w32term.c:w32_handle_tab_bar_click
=C2=A0 =C2=A0 =C2=A0 1. src/xdispl.c:handle_tab_bar_click
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. src/xdi= spl.c:get_tab_bar_item
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Returns whether the mouse's X/Y is o= n the same item that
=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
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other things, whether the = column position HPOS returned by
= =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
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0src/frame.h:MOUSE_HL_INFO'= s mouse face beg and end col range.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. if the above function indicates tha= t the mouse cursor is
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on the same item that was highlighted befor= e, then it
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 activates the tab.
=C2=A0

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
pays attention to the value of mouse-highlight.=C2=A0 But tab-bar buttons don't behave like tool-bar buttons in this regard: they don't respo= nd
to moving the mouse pointer to them by "activating" the button.= =C2=A0 So I
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
RET), and clicks on tab-bar buttons miraculously start working with
100% reliability.

This will indeed also solve the problem by removing the comparis= on in
B.1.1 which is using the po= tentially 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 p= art of the
code might have been i= ncluded 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 s= et the
src/w32term.h:FRAME_DISPLA= Y_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 coordina= tes during a mouse move (so that MOUSE_HL_INFO does not
contain stale information)? I can't think of a r= eason why we might want this to=C2=A0
be set using virtual-glyph coords when over the tab-bar (but then, I c= an only see some of=C2=A0
the pie= ces and not the whole picture as you do).
=C2=A0=C2=A0
Thanks!
--0000000000006c66e805bf2ae1af-- From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 04 19:05:07 2021 Received: (at 47581) by debbugs.gnu.org; 4 Apr 2021 23:05:07 +0000 Received: from localhost ([127.0.0.1]:36620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lTBnm-0003WV-VO for submit@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 ) id 1lTBnj-0003Vh-8t for 47581@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@linkov.net) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 68986240003; Sun, 4 Apr 2021 23:04:55 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows Organization: LINKOV.NET References: <83pmzbeajw.fsf@gnu.org> Date: Mon, 05 Apr 2021 02:00:47 +0300 In-Reply-To: <83pmzbeajw.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Apr 2021 16:56:35 +0300") Message-ID: <87mtudac4g.fsf@mail.linkov.net> 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 , 47581@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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; From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 11 05:22:00 2021 Received: (at 47581) by debbugs.gnu.org; 11 Apr 2021 09:22:00 +0000 Received: from localhost ([127.0.0.1]:54007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVWI4-0004bg-3P for submit@debbugs.gnu.org; Sun, 11 Apr 2021 05:22:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVWI2-0004bR-Ig for 47581@debbugs.gnu.org; Sun, 11 Apr 2021 05:21:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59114) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVWHw-0004Ea-FX; Sun, 11 Apr 2021 05:21:52 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2487 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lVWHv-0003MJ-Um; Sun, 11 Apr 2021 05:21:52 -0400 Date: Sun, 11 Apr 2021 12:21:31 +0300 Message-Id: <83h7kd41no.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87mtudac4g.fsf@mail.linkov.net> (message from Juri Linkov on Mon, 05 Apr 2021 02:00:47 +0300) Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows References: <83pmzbeajw.fsf@gnu.org> <87mtudac4g.fsf@mail.linkov.net> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47581 Cc: ioannis.kappas@gmail.com, 47581@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Juri Linkov > Cc: Ioannis Kappas , 47581@debbugs.gnu.org > Date: Mon, 05 Apr 2021 02:00:47 +0300 > > > 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. OK, I've fixed handle_tab_bar_click to not pay attention to mouse-highlight, please see if there are any adverse side effects of that change. I also removed note_tab_bar_highlight and the code which called it. I couldn't find any place which depended on that, and there was no visible effect of mouse-highlight on any part of the tab-bar buttons that I could see. If I missed something, please show a recipe where this highlight had any effect before my changes. (It _is_ possible to have the tab-bar buttons react to mouse pointer movements, but for that we need support in display code, which isn't there. If we will ever want to add mouse sensitivity to tab-bar buttons, we should first add code which displays those buttons differently when the draw_glyphs_face value is DRAW_MOUSE_FACE or DRAW_IMAGE_SUNKEN/RAISED; then we'd want to resurrect note_tab_bar_highlight that I deleted.) From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 11 05:24:34 2021 Received: (at 47581) by debbugs.gnu.org; 11 Apr 2021 09:24:34 +0000 Received: from localhost ([127.0.0.1]:54014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVWKX-0004fu-Pj for submit@debbugs.gnu.org; Sun, 11 Apr 2021 05:24:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVWKW-0004fi-Su for 47581@debbugs.gnu.org; Sun, 11 Apr 2021 05:24:33 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59134) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVWKR-0005pT-Nc; Sun, 11 Apr 2021 05:24:27 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2647 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lVWKR-0003hR-2U; Sun, 11 Apr 2021 05:24:27 -0400 Date: Sun, 11 Apr 2021 12:24:09 +0300 Message-Id: <83fszx41ja.fsf@gnu.org> From: Eli Zaretskii To: Ioannis Kappas In-Reply-To: (message from Ioannis Kappas on Sun, 4 Apr 2021 20:43:44 +0100) Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows References: <83pmzbeajw.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47581 Cc: 47581@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Ioannis Kappas > Date: Sun, 4 Apr 2021 20:49:24 +0100 > Cc: juri@linkov.net, 47581@debbugs.gnu.org > > 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! This should now be fixed on the master branch. > 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). If you can show some scenario where this causes real problems, I will look into it. In my testing, I saw no problems, and the coordinates I saw weren't wrong, in the sense that they missed some glyphs due to problems with glyph dimensions. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 11 18:33:24 2021 Received: (at 47581) by debbugs.gnu.org; 11 Apr 2021 22:33:24 +0000 Received: from localhost ([127.0.0.1]:56005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVidw-0003Kl-7J for submit@debbugs.gnu.org; Sun, 11 Apr 2021 18:33:24 -0400 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:41679) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVidu-0003KW-S5 for 47581@debbugs.gnu.org; Sun, 11 Apr 2021 18:33:23 -0400 X-Originating-IP: 91.129.96.157 Received: from mail.gandi.net (m91-129-96-157.cust.tele2.ee [91.129.96.157]) (Authenticated sender: juri@linkov.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 1DA0A40006; Sun, 11 Apr 2021 22:33:15 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows Organization: LINKOV.NET References: <83pmzbeajw.fsf@gnu.org> <87mtudac4g.fsf@mail.linkov.net> <83h7kd41no.fsf@gnu.org> Date: Mon, 12 Apr 2021 00:53:45 +0300 In-Reply-To: <83h7kd41no.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 11 Apr 2021 12:21:31 +0300") Message-ID: <878s5oebu6.fsf@mail.linkov.net> 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@gmail.com, 47581@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> 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. > > OK, I've fixed handle_tab_bar_click to not pay attention to > mouse-highlight, please see if there are any adverse side effects of > that change. > > I also removed note_tab_bar_highlight and the code which called it. I > couldn't find any place which depended on that, and there was no > visible effect of mouse-highlight on any part of the tab-bar buttons > that I could see. If I missed something, please show a recipe where > this highlight had any effect before my changes. Sorry, I don't understand the need to remove the highlighting code. Before the removal, the tab-bar button images reacted to mouse pointer movements, and highlighted the buttons under the mouse pointer using the pressed/released state DRAW_IMAGE_SUNKEN/RAISED. Now there is no visual feedback when the user moves the mouse pointer over the buttons. Doesn't seem like an improvement. > (It _is_ possible to have the tab-bar buttons react to mouse pointer > movements, but for that we need support in display code, which isn't > there. If we will ever want to add mouse sensitivity to tab-bar > buttons, we should first add code which displays those buttons > differently when the draw_glyphs_face value is DRAW_MOUSE_FACE or > DRAW_IMAGE_SUNKEN/RAISED; then we'd want to resurrect > note_tab_bar_highlight that I deleted.) Looks like a plan to re-add the same feature, but differently. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 11 22:31:45 2021 Received: (at 47581) by debbugs.gnu.org; 12 Apr 2021 02:31:45 +0000 Received: from localhost ([127.0.0.1]:56130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVmMb-0000mx-Gp for submit@debbugs.gnu.org; Sun, 11 Apr 2021 22:31:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVmMZ-0000mk-Lz for 47581@debbugs.gnu.org; Sun, 11 Apr 2021 22:31:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45498) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVmMT-0004mH-QY; Sun, 11 Apr 2021 22:31:37 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2933 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lVmMP-0000uv-MB; Sun, 11 Apr 2021 22:31:36 -0400 Date: Mon, 12 Apr 2021 05:31:17 +0300 Message-Id: <83pmz02pze.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <878s5oebu6.fsf@mail.linkov.net> (message from Juri Linkov on Mon, 12 Apr 2021 00:53:45 +0300) Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows References: <83pmzbeajw.fsf@gnu.org> <87mtudac4g.fsf@mail.linkov.net> <83h7kd41no.fsf@gnu.org> <878s5oebu6.fsf@mail.linkov.net> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47581 Cc: ioannis.kappas@gmail.com, 47581@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Juri Linkov > Cc: ioannis.kappas@gmail.com, 47581@debbugs.gnu.org > Date: Mon, 12 Apr 2021 00:53:45 +0300 > > > I also removed note_tab_bar_highlight and the code which called it. I > > couldn't find any place which depended on that, and there was no > > visible effect of mouse-highlight on any part of the tab-bar buttons > > that I could see. If I missed something, please show a recipe where > > this highlight had any effect before my changes. > > Sorry, I don't understand the need to remove the highlighting code. > Before the removal, the tab-bar button images reacted to mouse pointer > movements, and highlighted the buttons under the mouse pointer > using the pressed/released state DRAW_IMAGE_SUNKEN/RAISED. I didn't see any such effect, and couldn't find the code which supports this highlighting. Please point out what I missed. > Now there is no visual feedback when the user moves the mouse pointer > over the buttons. Doesn't seem like an improvement. There was no visual feedback before my changes on my system, so I really don't understand what you are describing. Were you seeing that in a GTK build or a build without GTK? > > (It _is_ possible to have the tab-bar buttons react to mouse pointer > > movements, but for that we need support in display code, which isn't > > there. If we will ever want to add mouse sensitivity to tab-bar > > buttons, we should first add code which displays those buttons > > differently when the draw_glyphs_face value is DRAW_MOUSE_FACE or > > DRAW_IMAGE_SUNKEN/RAISED; then we'd want to resurrect > > note_tab_bar_highlight that I deleted.) > > Looks like a plan to re-add the same feature, but differently. >From my POV, the feature was never there. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 12:14:25 2021 Received: (at 47581) by debbugs.gnu.org; 12 Apr 2021 16:14:25 +0000 Received: from localhost ([127.0.0.1]:57810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVzCj-0003O4-GN for submit@debbugs.gnu.org; Mon, 12 Apr 2021 12:14:25 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:49741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVzCi-0003Ne-4I for 47581@debbugs.gnu.org; Mon, 12 Apr 2021 12:14:24 -0400 X-Originating-IP: 91.129.96.157 Received: from mail.gandi.net (m91-129-96-157.cust.tele2.ee [91.129.96.157]) (Authenticated sender: juri@linkov.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 15B60E0004; Mon, 12 Apr 2021 16:14:16 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows Organization: LINKOV.NET References: <83pmzbeajw.fsf@gnu.org> <87mtudac4g.fsf@mail.linkov.net> <83h7kd41no.fsf@gnu.org> <878s5oebu6.fsf@mail.linkov.net> <83pmz02pze.fsf@gnu.org> Date: Mon, 12 Apr 2021 19:07:50 +0300 In-Reply-To: <83pmz02pze.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 12 Apr 2021 05:31:17 +0300") Message-ID: <87tuob1zah.fsf@mail.linkov.net> 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@gmail.com, 47581@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Sorry, I don't understand the need to remove the highlighting code. >> Before the removal, the tab-bar button images reacted to mouse pointer >> movements, and highlighted the buttons under the mouse pointer >> using the pressed/released state DRAW_IMAGE_SUNKEN/RAISED. > > I didn't see any such effect, and couldn't find the code which > supports this highlighting. Please point out what I missed. There was a clearly visible indication with raised images on mouse pointer movements over the tab close buttons. >> Now there is no visual feedback when the user moves the mouse pointer >> over the buttons. Doesn't seem like an improvement. > > There was no visual feedback before my changes on my system, so I > really don't understand what you are describing. Were you seeing that > in a GTK build or a build without GTK? The visual feedback was observable on GNU Linux build with GTK+ Version 3.24.20, cairo version 1.16.0. Maybe there were no such effects on a Windows build? From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 13 09:44:38 2021 Received: (at 47581) by debbugs.gnu.org; 13 Apr 2021 13:44:38 +0000 Received: from localhost ([127.0.0.1]:59323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWJLK-0004dh-G3 for submit@debbugs.gnu.org; Tue, 13 Apr 2021 09:44:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWJLI-0004dU-QU for 47581@debbugs.gnu.org; Tue, 13 Apr 2021 09:44:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50210) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWJLC-0008FJ-Ax; Tue, 13 Apr 2021 09:44:30 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1592 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lWJLB-0006Dw-Il; Tue, 13 Apr 2021 09:44:30 -0400 Date: Tue, 13 Apr 2021 16:44:15 +0300 Message-Id: <83o8ei1eq8.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87tuob1zah.fsf@mail.linkov.net> (message from Juri Linkov on Mon, 12 Apr 2021 19:07:50 +0300) Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows References: <83pmzbeajw.fsf@gnu.org> <87mtudac4g.fsf@mail.linkov.net> <83h7kd41no.fsf@gnu.org> <878s5oebu6.fsf@mail.linkov.net> <83pmz02pze.fsf@gnu.org> <87tuob1zah.fsf@mail.linkov.net> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47581 Cc: ioannis.kappas@gmail.com, 47581@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Juri Linkov > Cc: ioannis.kappas@gmail.com, 47581@debbugs.gnu.org > Date: Mon, 12 Apr 2021 19:07:50 +0300 > > >> Sorry, I don't understand the need to remove the highlighting code. > >> Before the removal, the tab-bar button images reacted to mouse pointer > >> movements, and highlighted the buttons under the mouse pointer > >> using the pressed/released state DRAW_IMAGE_SUNKEN/RAISED. > > > > I didn't see any such effect, and couldn't find the code which > > supports this highlighting. Please point out what I missed. > > There was a clearly visible indication with raised images > on mouse pointer movements over the tab close buttons. Only on the tab close buttons? I thought you were talking about the button as a whole: those don't react to mouse movements, at least here. Anyway, I've restored the mouse sensitivity of the tab-close buttons. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 13 12:21:10 2021 Received: (at 47581) by debbugs.gnu.org; 13 Apr 2021 16:21:11 +0000 Received: from localhost ([127.0.0.1]:60617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWLmo-0002R3-Hp for submit@debbugs.gnu.org; Tue, 13 Apr 2021 12:21:10 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:60869) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWLmm-0002Qc-Dw for 47581@debbugs.gnu.org; Tue, 13 Apr 2021 12:21:08 -0400 X-Originating-IP: 91.129.96.157 Received: from mail.gandi.net (m91-129-96-157.cust.tele2.ee [91.129.96.157]) (Authenticated sender: juri@linkov.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id B6DE21BF210; Tue, 13 Apr 2021 16:21:01 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows Organization: LINKOV.NET References: <83pmzbeajw.fsf@gnu.org> <87mtudac4g.fsf@mail.linkov.net> <83h7kd41no.fsf@gnu.org> <878s5oebu6.fsf@mail.linkov.net> <83pmz02pze.fsf@gnu.org> <87tuob1zah.fsf@mail.linkov.net> <83o8ei1eq8.fsf@gnu.org> Date: Tue, 13 Apr 2021 19:14:43 +0300 In-Reply-To: <83o8ei1eq8.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 13 Apr 2021 16:44:15 +0300") Message-ID: <87tuoa88lo.fsf@mail.linkov.net> 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@gmail.com, 47581@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> There was a clearly visible indication with raised images >> on mouse pointer movements over the tab close buttons. > > Only on the tab close buttons? I thought you were talking about the > button as a whole: those don't react to mouse movements, at least > here. > > Anyway, I've restored the mouse sensitivity of the tab-close buttons. I confirm that now the tab close buttons react to mouse movements as before, and also there is no more issue of missed mouse clicks reported by Ioannis. But tested only on GNU/Linux, I can't confirm for MS-Windows. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 13 12:34:02 2021 Received: (at 47581-done) by debbugs.gnu.org; 13 Apr 2021 16:34:02 +0000 Received: from localhost ([127.0.0.1]:60645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWLzG-0002lc-1b for submit@debbugs.gnu.org; Tue, 13 Apr 2021 12:34:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWLzE-0002l8-2W for 47581-done@debbugs.gnu.org; Tue, 13 Apr 2021 12:34:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53836) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWLz1-00020K-Ey; Tue, 13 Apr 2021 12:33:51 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4194 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lWLz0-0002aF-Cv; Tue, 13 Apr 2021 12:33:47 -0400 Date: Tue, 13 Apr 2021 19:33:32 +0300 Message-Id: <83fszu16w3.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87tuoa88lo.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 13 Apr 2021 19:14:43 +0300) Subject: Re: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows References: <83pmzbeajw.fsf@gnu.org> <87mtudac4g.fsf@mail.linkov.net> <83h7kd41no.fsf@gnu.org> <878s5oebu6.fsf@mail.linkov.net> <83pmz02pze.fsf@gnu.org> <87tuob1zah.fsf@mail.linkov.net> <83o8ei1eq8.fsf@gnu.org> <87tuoa88lo.fsf@mail.linkov.net> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 47581-done Cc: ioannis.kappas@gmail.com, 47581-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Juri Linkov > Cc: ioannis.kappas@gmail.com, 47581@debbugs.gnu.org > Date: Tue, 13 Apr 2021 19:14:43 +0300 > > >> There was a clearly visible indication with raised images > >> on mouse pointer movements over the tab close buttons. > > > > Only on the tab close buttons? I thought you were talking about the > > button as a whole: those don't react to mouse movements, at least > > here. > > > > Anyway, I've restored the mouse sensitivity of the tab-close buttons. > > I confirm that now the tab close buttons react to mouse movements as before, > and also there is no more issue of missed mouse clicks reported by Ioannis. > But tested only on GNU/Linux, I can't confirm for MS-Windows. Thanks. I tested on Windows, so I think we can close this. From unknown Sun Jun 22 00:54:45 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 12 May 2021 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator