[ros-diffs] [reactos] 01/01: [CONSRV] Work-around buggy WM_MOUSEMOVE events received when VBox Mouse Integration is enabled. (#5441) CORE-8394

[Hermès Bélusca-Maïto]

https://git.reactos.org/?p=reactos.git;a=commitdiff;h=97277b4deb998fb2e6ddb…

commit 97277b4deb998fb2e6ddb6a632c455f1dcccbd53
Author:     Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org>
AuthorDate: Thu Jul 13 23:00:05 2023 +0200
Commit:     Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org>
CommitDate: Sun Jul 16 19:13:14 2023 +0200

    [CONSRV] Work-around buggy WM_MOUSEMOVE events received when VBox Mouse Integration is
enabled. (#5441)
    CORE-8394
    
    These caused the "Ignore-next-mouse-event" mechanism of the console
    (used e.g. in QuickEdit mode for not triggering the appearance of the
    context menu, etc.) to not work.
    
    Please note that these buggy events, that arise when testing ReactOS
    in VirtualBox with Mouse Integration is enabled, do not show up when
    running instead Windows (2003, ...) in the same configured VM.
    
    Addendum to commits ac51557 (r63792) and 33d8a4b (r67218).
    
    Improved fix for the one reported in PR #5406 by contributor 'whindsaks',
    as it keeps the separation between the flag that manages the working-around
    of the bug, and the other flag that is used for ignoring the genuine next
    mouse event that follows mouse-button-down events.
---
 win32ss/user/winsrv/consrv/frontends/gui/conwnd.c | 36 ++++++++++++++++++-----
 1 file changed, 29 insertions(+), 7 deletions(-)

diff --git a/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c
b/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c
index 12e14f9cec8..42a8288073e 100644
--- a/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c
+++ b/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c
@@ -1778,6 +1778,29 @@ OnMouse(PGUI_CONSOLE_DATA GuiData, UINT msg, WPARAM wParam, LPARAM
lParam)
                 DoDefault = TRUE; // FALSE;
                 break;
         }
+
+        /*
+         * HACK FOR CORE-8394 (Part 1):
+         *
+         * It appears that when running ReactOS on VBox with Mouse Integration
+         * enabled, the next mouse event coming after a button-down action is
+         * a mouse-move. However it is NOT always a rule, so that we cannot use
+         * the IgnoreNextMouseEvent flag to just "ignore" the next mouse
event,
+         * thinking it would always be a mouse-move event.
+         *
+         * To work around this problem (that should really be fixed in Win32k),
+         * we use a second flag to ignore this possible next mouse move event.
+         */
+        switch (msg)
+        {
+            case WM_LBUTTONDOWN:
+            case WM_MBUTTONDOWN:
+            case WM_RBUTTONDOWN:
+            case WM_XBUTTONDOWN:
+                GuiData->HackCORE8394IgnoreNextMove = TRUE;
+            default:
+                break;
+        }
     }
     else if (GetConsoleInputBufferMode(Console) & ENABLE_MOUSE_INPUT)
     {
@@ -1920,15 +1943,14 @@ OnMouse(PGUI_CONSOLE_DATA GuiData, UINT msg, WPARAM wParam, LPARAM
lParam)
         /*
          * HACK FOR CORE-8394 (Part 1):
          *
-         * It appears that depending on which VM ReactOS runs, the next mouse
-         * signal coming after a button-down action can be a mouse-move (e.g.
-         * on VBox, whereas on QEMU it is not the case). However it is NOT a
-         * rule, so that we cannot use the IgnoreNextMouseSignal flag to just
-         * "ignore" the next mouse event, thinking it would always be a
mouse-
-         * move signal.
+         * It appears that when running ReactOS on VBox with Mouse Integration
+         * enabled, the next mouse event coming after a button-down action is
+         * a mouse-move. However it is NOT always a rule, so that we cannot use
+         * the IgnoreNextMouseEvent flag to just "ignore" the next mouse
event,
+         * thinking it would always be a mouse-move event.
          *
          * To work around this problem (that should really be fixed in Win32k),
-         * we use a second flag to ignore this possible next mouse move signal.
+         * we use a second flag to ignore this possible next mouse move event.
          */
         switch (msg)
         {