On Sat, 24 Oct 2026 13:17:53 GMT, Thiago Milczarek Sayao <[email protected]> wrote:
> In Glass GTK, `sm_mouse_drag_window` tracks which window holds the pointer > grab during a mouse drag. > > The variable is cleared only when a button-release event reaches Glass or > when the window is destroyed. > > During a drag-and-drop operation, however, `gtk_drag_begin()` takes its own > pointer grab and consumes the button-release event. As a result, when > `execute_dnd()` returns, `sm_mouse_drag_window` may still point to the source > window. > > ### Cause > > The fix for JDK-8292922 removed the call to `ungrab_mouse_drag_focus()` on > focus-out events. > > Previously, creating a new `Stage` from a drag handler could steal focus, > triggering this call and cancelling the drag's pointer grab. > > With that call removed, the stale state is no longer cleaned up, exposing the > underlying issue. > > **JDK-8375965 — Dialog buttons stop responding after DnD** > > After a DnD operation, the dialog appears, but any subsequent cursor change > re-grabs the pointer onto the main window. As a result, mouse events are > redirected to the main window, preventing the dialog's buttons from receiving > clicks. > > **JDK-8395594 — ContextMenu becomes unresponsive after DnD** > > When a `ContextMenu` is shown, `grab_focus()` detects the stale drag window > and skips the actual grab. A subsequent `set_cursor()` redirects all mouse > events to the main window, making the menu appear frozen while clicks are > delivered to the underlying scene. > > ### Fix > > Call the new static method `WindowContextBase::reset_mouse_drag_focus()` > after the DnD loop in `execute_dnd()`. > > This method performs the cleanup that would normally occur when the > button-release event reaches Glass: it clears `sm_mouse_drag_window`, > releases the pointer grab, and restores the popup's grab if one exists. > > By resetting the state immediately after the DnD loop, the fix addresses the > problem at its source while preserving the behavior introduced by JDK-8292922. > > > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). I've updated the PR description. Both issues are related to sm_mouse_drag_window not being cleared, but they occur in different scenarios. I wouldn't consider them the same issue, although they share the same underlying cause. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2353#issuecomment-6466820297
