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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ioannis Kappas <ioannis.kappas <at> gmail.com>
Cc: 47581 <at> debbugs.gnu.org
Subject: bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows
Date: Sun, 11 Apr 2021 12:24:09 +0300

> From: Ioannis Kappas <ioannis.kappas <at> gmail.com>
> Date: Sun, 4 Apr 2021 20:49:24 +0100
> Cc: juri <at> linkov.net, 47581 <at> 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.

Previous Next

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