On Mon, 14 Jul 2025 21:48:03 GMT, Martin Fox <m...@openjdk.org> wrote:
>What does it mean to integrate this? We would be adding a test designed to >fail with the default testing environment. After failure a developer would >have to re-run with the no daemon flag set. Shouldn't that become the default? I agree that this way of running the tests should be the default but there is no way (as far as I know) to do this from the project level. The only path would be to add a `gradle.properties` file in the project root but we don't have one and it is ignored via gitignore. We only have a template which you need to copy-paste and rename to `gradle.properties`. As I understand it, different developers might need different ways of configuring gradle for their own needs, which should not be pushed to the repository or tracked by Git as meaningful changes. According to [Gradle manual](https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon) other ways to disable the daemon are user-specific (`--no-daemon` flag, user-wide or system-wide property). >If not, can we ensure this test runs early so it truly serves as a canary test? I am not sure if that is possible, the only thing coming to my mind is executing that test specifically via `build.gradle` before running the whole suite. I'd be happy to get suggestions if anyone else knows something (ex. from JUnit) that could help it. >Should folks developing new tests assume that they don't have to add the usual >workarounds like sending a mouse click to the window? Some tests did that, some tests did not. This whole ordeal started because `MenuDoubleShortcutTest` seemingly crashed mid-execution, later I found out the problem is Windows' focus stealing policy when you run the tests - test window was not in focus, the terminal was, so when the test program sent Ctrl+C for test purposes it was delivered to the terminal with obvious results. Before that was the case (and judging by how native calls like `_setVisible` behave) the assumption was that showing the Stage means it gets focus. I have a patch queued up after this gets introduced which fixes the problem we talked about earlier with `Window.isFocused()` API being incorrect. Ideally I would hope that tests requiring sending some inputs to the Stage will call that function and fail early (like some other tests already do). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3072831587
