JDK-8292922 : [Linux] No more drag events when new Stage is created in drag handler
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: jfx11,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-08-25
  • Updated: 2023-12-05
  • Resolved: 2022-12-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
jfx17.0.10Fixed
Related Reports
Blocks :  
JDK-8260528 - Clean glass-gtk sizing and positioning code
Description
The issue exists in all versions since java8, and only on Linux (Windows and Mac OS X are fine).  
It is a blocker for any docking framework based on dragging an undecorated stage as opposed to drag-and-drop, see

https://github.com/andy-goryachev/FxDock/issues/6
https://github.com/kasemir/FxDocking/issues/1

To reproduce:
- launch and try dragging the red label around

Expected results:
- an undecorated translucent stage is created and is dragged around

Actual results:
- the stage gets stuck and cannot be dragged
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jfx17u/pull/170 Date: 2023-12-05 11:02:14 +0000
05-12-2023
Changeset: a35c3bf7 Author: Thiago Milczarek Sayao <tsayao@openjdk.org> Date: 2022-12-23 17:40:37 +0000 URL: https://git.openjdk.org/jfx/commit/a35c3bf78b86c57d6e80d592e99f16ab349b0d8c
23-12-2022
I have closed Draft PR #905 PR #977 implements approach 2, and is the more direct approach. It will need testing to ensure no regressions. We can discuss it in the PR.
19-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jfx/pull/977 Date: 2022-12-18 20:28:17 +0000
18-12-2022
NOTE: this is now blocked by JDK-8260528. After that is integrated we will discuss the best approach to implement the fix for this bug. There are (at least) two possible approaches: 1. The approach I prototyped in Draft PR: https://github.com/openjdk/jfx/pull/905 2. Calling gdk_device_grab when a drag event is started (and gdk_device_ungrab when the drag ends)
17-12-2022
Thank you [~kcr] for taking a look! The current changes allow the FxDock https://github.com/andy-goryachev/FxDock to drag the transient window around as expected. The only problem encountered so far is that when the user drops the transient on a desktop and a new FxDockWindow (==Stage) is created, it is placed underneath the source stage. It is not the case on Windows and Mac, where the new window is created on top of all other windows. Adding requestFocus() and toFront() right after the framework creates the new window does not help. One thing that might be relevant: right before the new window gets shown, the opacity is set to 0, when show(), then opacity is set to the initial value. As the comment in DockTools:731 tells, it was done to combat some flicker. Removing that hack did not produce flicker on Linux, but also had no effect on the issue - the new widow is still behind the source one.
29-08-2022
I have a preliminary fix that is being tested now. Also, I attached a slightly modified version of the failing test program, DragFailure2.java. The only real difference is that it creates a Scene and adds that to the Stage (else it doesn't render correctly on Windows or Linux: a Scene-less Stage is not expected and isn't well supported). In order to still render it as transparent, I set the stage style to TRANSPARENT and filled the scene with a 50% opaque fill color.
29-08-2022
We can't rely on global desktop settings (not sure it would help anyway). The fix should be pretty easy in our code I think. It's mostly a matter of testing and making sure the fix is robust. We've had a few focus-related bugs over the past couple years on Linux, so we want to make sure we don't regress anywhere.
26-08-2022
Not a Linux expect, but I do recall an X11 option to focus window on mouse over - could it be relevant in this case? edit: the name of the feature is "focus follows mouse" or "sloppy focus" ``` gsettings set org.gnome.desktop.wm.preferences focus-mode 'mouse'|'sloppy'|'click' ```
26-08-2022
Thank you, [~kcr], for looking into this. This has been a long standing issue (4+ years) with no workaround that prevented linux support in one product I worked on. I wonder what it would take to have it fixed in jfx20?
26-08-2022
It's definitely a window focus bug. If I disable focus for the native peer of the second Stage at window creation time, everything works correctly. So a fix might be to prevent focus selection (maybe by disabling focus initially and re-enabling it later or by suppressing the initial focus grab) if a window is created while a drag operation is in progress. We will need to fix it in such a way that we don't lose the ability of a secondary window to later gain focus. We could consider fixing this for JavaFX 20.
26-08-2022
I spent some time testing this, and the problem is that drag events stop being delivered after a while if a second stage is created from the drag handler. If instead the window is created ahead of time (and moved out of the way), it works perfectly. This points to a focus problem. I suspect what is happening is that when the second window is created and grabs focus, it interrupts the in-progress drag.
25-08-2022
tried to delay creating the second stage to MOUSE_DRAGGED, still fails. (I recall I've tried all sorts of things before trying to make it work).
25-08-2022
I attached a program with a single undecorated Stage that can be dragged around. This works on all platforms. I can reproduce the bug with the DragFailure program on Linux. My guess is that the failing case is hitting some sort of focus bug or mouse event delivery bug related to have two stages, one of which is created from the drag handler.
25-08-2022
Thanks, I'll give that a try. As an experiment (and before I looked at the attached test program), I took a simple JavaFX program with an undecorated stage, and added a quick prototype custom event handler to move it around. It works fine for me on Linux. I'll clean it up and attach it. Likely something that the attached test program is doing is hitting a case that my simple program doesn't, so comparing them might make sense.
25-08-2022
a test case is attached.
25-08-2022
This is almost certainly a window-toolkit (glass) bug rather than a controls bug.
25-08-2022
screenshot: https://user-images.githubusercontent.com/1932421/37210447-b9abb28c-2376-11e8-9ead-034fdac8cf39.png
25-08-2022