RFR: 8351357: Add canary system test checking if Stage receives focus on show [v4]
Andy Goryachev
angorya at openjdk.org
Mon Jun 30 17:00:51 UTC 2025
On Mon, 30 Jun 2025 14:33:01 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:
>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>>
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>>
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>>
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>>
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>
> Review fixes; rewrite test to extend VisualTestBase
tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 118:
> 116: Util.runAndWait(() -> {
> 117: Color color = getColor(STAGE_SIZE / 2, STAGE_SIZE / 2);
> 118: assertColorEquals(Color.LIGHTGREEN, color, TOLERANCE);
I wonder if this implementation is a reliable test: the stage in question may be overlapped by another window somewhere in the corner, right?
What would be a reliable test? Strictly speaking, we must check every pixel in the scene, though I wonder if checking each pixel in a grid (maybe 20 x 20, since we don't expect any reasonable window to be less than that) should be enough?
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2175524744
More information about the openjfx-dev
mailing list