[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows
From: |
Eli Zaretskii |
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@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.
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, (continued)
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, Eli Zaretskii, 2021/04/03
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, Juri Linkov, 2021/04/04
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, Eli Zaretskii, 2021/04/11
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, Juri Linkov, 2021/04/11
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, Eli Zaretskii, 2021/04/11
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, Juri Linkov, 2021/04/12
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, Eli Zaretskii, 2021/04/13
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, Juri Linkov, 2021/04/13
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows, Eli Zaretskii, 2021/04/13
- Message not available
- bug#47581: 27.1; tab-bar missed mouse clicks on MS-Windows,
Eli Zaretskii <=