JDK-8321624 : DualWindowTest fails intermittently on Linux
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: jfx22
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • Submitted: 2023-12-08
  • Updated: 2025-04-26
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
tbdUnresolved
Related Reports
Relates :  
JDK-8321625 - [testbug] ContextMenuNPETest fails intermittently on Linux
Relates :  
JDK-8354943 - [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues
Relates :  
JDK-8321626 - [testbug] Mark DualWindowTest and ContextMenuNPETest unstable on Linux
Description
The following headful system test fails intermittently on Linux. We see this failure quite often in our automated test runs.

DualWindowTest > testTwoStages FAILED
    java.lang.AssertionError: expected:<400.0> but was:<860.0>
        at org.junit.Assert.fail(Assert.java:89)
        at org.junit.Assert.failNotEquals(Assert.java:835)
        at org.junit.Assert.assertEquals(Assert.java:555)
        at org.junit.Assert.assertEquals(Assert.java:685)
        at test.robot.javafx.stage.DualWindowTest.lambda$testTwoStages$3(DualWindowTest.java:158)
Comments
I managed to reproduce it on Ubuntu 22.04 VM. It fails on average once every 5 to 10 runs. The reason for failure is that second Stage created for the purpose of this test is not moved to correct position, instead it remains centered. After diving more into this, on Linux we set the window position via gtk_window_move(). Spec for this function - https://docs.gtk.org/gtk3/method.Window.move.html - says: "Window managers are free to ignore this; most window managers ignore requests for initial window positions (instead using a user-defined placement algorithm) and honor requests after the window has already been shown." I did notice that window moves are not 100% consistently applied when the window is not fully shown - extracting window position right after gtk_window_move() by using gtk_window_get_position() shows that for first few attempts the window move is ignored, and only after the window is fully shown gtk_window_move() has an effect. The test changes Stage's X/Y coordinates properly - via addEventListener(WindowEvent.WINDOW_SHOWN) - so my suspicion is that this is a race condition between us and the window manager - we incorrectly (or not at all) detect when the window is "fully" shown. This is also seen by putting a small Thread.sleep() in above event listener, it gives the window manager a chance to catch up and fully show the window, and the test then starts to consistently pass. I would reclassify this not as a testbug, but rather as a platform bug and come back to this later. The stabilization fix should probably happen in Glass code using GTK.
28-03-2025
Pausing work on this issue - I wasn't able to reproduce it locally, I only managed to do it occasionally on our automated test run suite (which takes a long while to see the results). I'll come back to this one once I have more time to properly dig into it.
14-03-2024
This is causing a lot of noise in our CI headful test runs, so we will mark this test as unstable on Linux. See JDK-8321626.
09-12-2023