I ran the then latest version of the test from PR 1283 yesterday
afternoon, and for me it passed on both M1 and M2. I didn't try it on an
Intel Mac, but will do so this morning.
I hadn't noticed any problems with our other tests when getting things
running on macOS 14 (beyond the bugs we already fixed related to
activation), but I'll take a closer look at them. It's certainly
possible we have other tests that are "passing" because they never get
activated.
-- Kevin
On 1/12/2024 12:40 AM, Johan Vos wrote:
Hi Martin,
Great analysis, and that sounds very well possible. Indeed, there is a
specific launch approach for the systemtests where the launch command
is created (in tests/system/src/test/java/test/util/Util).
It is still unclear to me why this would happen on M2 only (and not on
M1 or Intel), but maybe there is no causal relation. In any case, this
means that we have to rethink how to do the system tests, as people
(including me) can falsely assume that all tests passed correctly.
- Johan
On Thu, Jan 11, 2024 at 6:18 PM Martin Fox <m_r_...@sbcglobal.net> wrote:
Johan,
I think I see what’s going on (maybe). When I run the test app
from gradle it fails to activate. I suspect this is due to changes
in macOS 14 that makes it harder for an application to come to the
front and start grabbing keyboard input while the user is
interacting with another app. Search for "macos cooperative
activation” (I’m leery of adding a link since it might trigger a
spam filter).
When I run a JavaFX app from Terminal it allows the Java app to
activate unless I have Terminal > Secure Keyboard Entry turned on
in which case the app comes to the front but doesn’t activate.
That setting doesn’t make a difference when running a test from
Gradle. No idea why you would see different behavior on M2 vs Intel.
I ran into this on Windows which has had this sort of protection
for a long time. I was only having trouble when running a test app
using Gradle and the msys2 shell (it worked with Cygwin). There’s
a set of rules that govern the handoff but I could never figure
out which one was failing. The solution there was to use a Robot
to synthesize a mouse click on the window.
This all suggests that gradle is spawning a background process and
launching the JavaFX app from there. On both Windows and macOS 14
that could trigger this security/privacy feature.
Martin
On Jan 11, 2024, at 5:40 AM, Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
Hi Johan,
I can also try this today, since I have an M1 laptop and have
access to an M2 Mac Mini, both running macOS 14.x.
-- Kevin
On 1/11/2024 12:08 AM, Johan Vos wrote:
Hi Martin,
Thanks for testing this. Just to make sure: the fact that the
systemtest pass, is the problem. It shouldn't pass. The change
in PR 1283 caused regression that I didn't notice on the M2, but
I heard the test correctly fails on M1, and I could confirm it
correctly fails on Mac/Intel as well.
Now that I know that this is not just my local M2 setup, I can
have a look at the cause -- thanks for your useful feedback!
- Johan
On Wed, Jan 10, 2024 at 7:58 PM Martin Fox
<m_r_...@sbcglobal.net> wrote:
Johan,
Are you referring to PR 1283? And are you seeing test
failures on Intel or M2?
I just grabbed PR 1283 and the system test works fine on my
M2 Mac. As for JDK-8089848 I recently looked into that and
it was very specific to changing the focus while processing
windowDidResignKey (though I suppose it could also happen if
you changed focus while processing windowDidBecomeKey). In
that bug I didn’t see any cases where windowDidBecomeKey
wasn’t called, just cases where it was called on the wrong
window. I don’t see any obvious smoking guns in the
SystemMenuBarTest that would lead to the same condition.
Martin
On Jan 10, 2024, at 2:10 AM, Johan Vos
<johan....@gluonhq.com> wrote:
I noticed different test results when running systemtests
on a mac/intel versus an M2.
when running systemtests from a command line using
`sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest
:systemTests:test
--tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest`
I traced it down to `windowDidBecomeKey` on
`GlassWindow+Overrides.m` not being called on the M2. That
of course leads to different paths, hence different test
results.
I wonder if this is somehow related to
https://bugs.openjdk.org/browse/JDK-8089848. Before looking
into this, is this something others observed as well?
- Johan
