RFR: 8292922 - [Linux] No more drag events when new Stage is created in drag handler [v3]

[Thiago Milczarek Sayao]

On Sun, 18 Dec 2022 21:02:20 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This PR  was previously discussed on #905.
>> 
>> The approach is to grab the keyboard focus so the window that originated the drag will keep it.
>> 
>> I did some cleanup on grabbing related functions as well.
>> 
>> `gdk_keyboard_focus()` is deprecated, so is `gdk_device*` functions in favor of `gdk_seat*`. But that's only available in later Gtk versions. I checked and newer Gtk will use `gdk_seat*` inside the deprecated `gdk_keyboard_focus()`.
>
> Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8292922 - [Linux] No more drag events when new Stage is created in drag handler

This one deserves a laught. Just commenting the `ungrab_mouse_drag_focus();` on focus lost fixes the problem. I will rework it. 


void WindowContextBase::process_focus(GdkEventFocus* event) {
    if (!event->in && WindowContextBase::sm_mouse_drag_window == this) {
        ungrab_mouse_drag_focus();
    }
//    if (!event->in && WindowContextBase::sm_mouse_drag_window == this) {
//        ungrab_mouse_drag_focus();
//    }
    if (!event->in && WindowContextBase::sm_grab_window == this) {
        ungrab_focus();
    }


The rationale is that `glass_gdk_mouse_devices_grab_with_cursor` grabs motion events so it keeps coming to the window, but there's an explicit "stop grabbing" on focus lost.

-------------

PR: https://git.openjdk.org/jfx/pull/977