bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Ioannis Kappas]

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''

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Ioannis Kappas]

[-- Attachment #1: Type: text/plain, Size: 3561 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6832 bytes --]

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Eli Zaretskii]

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> 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;

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Juri Linkov]

> 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;

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Ioannis Kappas <ioannis.kappas@gmail.com>,  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.)

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Juri Linkov]

>> 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.

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> 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.

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Juri Linkov]

>> 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?

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> 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.

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Juri Linkov]

>> 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.

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> 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.

bug#47581: Fwd: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Ioannis Kappas]

[-- Attachment #1: Type: text/plain, Size: 5529 bytes --]

Hi Eli,

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, 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!

[-- Attachment #2: Type: text/html, Size: 9926 bytes --]

bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows

[Eli Zaretskii]

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> 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.