Merge 7235dddefd into 7ef6efeb66

Wayland: Fix cursor position after a modal
If a modal surface like the window menu was active, clicking on the GLFW window content area to close it would correctly emit the cursor enter event but would not propagate the cursor position from the event.
2025-12-21 14:42:06 +00:00 · 2025-08-19 09:10:32 +08:00 · 2025-08-18 20:58:12 +02:00 · 2025-08-18 18:06:46 +02:00 · 2025-08-18 18:06:46 +02:00 · 2025-04-04 02:55:49 +02:00
3 changed files with 32 additions and 10 deletions
--- a/README.md
+++ b/README.md
@ -139,10 +139,16 @@ information on what to include when reporting a bug.
                     fallback decorations
 - [Wayland] Bugfix: Fallback decorations would report scroll events
 - [Wayland] Bugfix: Keyboard repeat events halted when any key is released (#2568)
+ - [Wayland] Bugfix: Fallback decorations would show menu at wrong position
+ - [Wayland] Bugfix: The cursor was not updated when clicking through from
+   a modal to a fallback decoration
+ - [Wayland] Bugfix: The cursor position was not updated when clicking through
+   from a modal to the content area
 - [X11] Bugfix: Running without a WM could trigger an assert (#2593,#2601,#2631)
 - [Null] Added Vulkan 'window' surface creation via `VK_EXT_headless_surface`
 - [Null] Added EGL context creation on Mesa via `EGL_MESA_platform_surfaceless`
 - [EGL] Allowed native access on Wayland with `GLFW_CONTEXT_CREATION_API` set to
+ - [Win32] Bugfix: Extended scancode of 0 was not being processed correctly
   `GLFW_NATIVE_CONTEXT_API` (#2518)


--- a/src/win32_window.c
+++ b/src/win32_window.c
@ -711,11 +711,11 @@ static LRESULT CALLBACK windowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM l
            const int mods = getKeyMods();

            scancode = (HIWORD(lParam) & (KF_EXTENDED | 0xff));
-            if (!scancode)
+            if (scancode == 0x100)
            {
-                // NOTE: Some synthetic key messages have a scancode of zero
+                // NOTE: Some synthetic key messages have a scancode of extended zero
                // HACK: Map the virtual key back to a usable scancode
-                scancode = MapVirtualKeyW((UINT) wParam, MAPVK_VK_TO_VSC);
+                scancode = KF_EXTENDED | MapVirtualKeyW((UINT) wParam, MAPVK_VK_TO_VSC);
            }

            // HACK: Alt+PrtSc has a different scancode than just PrtSc
--- a/src/wl_window.c
+++ b/src/wl_window.c
@ -405,13 +405,19 @@ static void handleFallbackDecorationButton(_GLFWwindow* window,
    }
    else if (button == BTN_RIGHT)
    {
-        if (window->wl.xdg.toplevel)
-        {
-            xdg_toplevel_show_window_menu(window->wl.xdg.toplevel,
-                                          _glfw.wl.seat, serial,
-                                          window->wl.cursorPosX,
-                                          window->wl.cursorPosY);
-        }
+        if (!window->wl.xdg.toplevel)
+            return;
+
+        if (window->wl.fallback.focus != window->wl.fallback.top.surface)
+            return;
+
+        if (ypos < GLFW_BORDER_SIZE)
+            return;
+
+        xdg_toplevel_show_window_menu(window->wl.xdg.toplevel,
+                                      _glfw.wl.seat, serial,
+                                      xpos,
+                                      ypos - GLFW_CAPTION_HEIGHT - GLFW_BORDER_SIZE);
    }
 }

@ -1532,11 +1538,21 @@ static void pointerHandleEnter(void* userData,
        window->wl.hovered = GLFW_TRUE;
        _glfwSetCursorWayland(window, window->wl.currentCursor);
        _glfwInputCursorEnter(window, GLFW_TRUE);
+
+        if (window->cursorMode != GLFW_CURSOR_DISABLED)
+        {
+            window->wl.cursorPosX = wl_fixed_to_double(sx);
+            window->wl.cursorPosY = wl_fixed_to_double(sy);
+            _glfwInputCursorPos(window, window->wl.cursorPosX, window->wl.cursorPosY);
+        }
    }
    else
    {
        if (window->wl.fallback.decorations)
+        {
            window->wl.fallback.focus = surface;
+            updateFallbackDecorationCursor(window, sx, sy);
+        }
    }
 }
Author	SHA1	Message	Date
Grzesiek11	341aaefa40	Merge `7235dddefd` into `7ef6efeb66`	2025-08-19 09:10:32 +08:00
Camilla Löwy	7ef6efeb66	Wayland: Fix cursor position after a modal If a modal surface like the window menu was active, clicking on the GLFW window content area to close it would correctly emit the cursor enter event but would not propagate the cursor position from the event.	2025-08-18 20:58:12 +02:00
Camilla Löwy	3cf9f6726d	Wayland: Fix fallback decoration cursor updating When a click through to the fallback decorations caused the end of a modal like the window menu, the cursor shape would not be updated until the next time the cursor moved. This commit adds an update of the cursor for the pointer enter event for fallback decoration surfaces, in addition to the updates at pointer motion events.	2025-08-18 18:06:46 +02:00
Camilla Löwy	bfa1c424e5	Wayland: Fix fallback decoration menu placement The fallback decorations would place the menu at the wrong position, by not translating the last decoration surface position into toplevel surface coordinates. This also limits the menu to the caption area of the top decoration surface, similar to how other toolkits work.	2025-08-18 18:06:46 +02:00
Grzesiek11	7235dddefd	Fix extended scancode of 0 not being processed correctly On Windows, keyboard events with an extended 0 Windows scancode are now processed by mapping the virtual-key code to a Windows scancode using the Win32 MapVirtualKey function. Some keyboard scancodes (in particular, ones used for some non-typical keys) are not mapped to corresponding Windows scancodes, and are instead mapped to an extended 0 Windows scancode, with the distinction being only in the virtual-key code. This causes GLFW to report a 256 GLFW scancode (0x00 \| 0x100, 0x100 being the extended bit bitmask) for any of those keys, which causes API consumers to be unable to distinguish between them. There exists, however, a Win32 function MapVirtualKey that maps those virtual key-codes to proper Windows scancodes. GLFW even appears to use this workaround, but after further inspection, it checks whether the Windows scancode is 0 (0x00), and not extended 0 (0x100). This change makes GLFW check for the extended 0 keycode instead, which seems to work correctly. I'm not sure if checking for the non-extended 0 Windows scancode was intentional, as I never seem to have encountered one during testing with multiple keyboards. Thus, the handling of the non-extended 0 Windows scancode was removed, but it can be brought back if necessary.	2025-04-04 02:55:49 +02:00