Yeah, I just realized that you had fixed it prior to my running the
tests yesterday afternoon. I reverted your most recent commit and it now
fails for me, as expected, on my Intel Mac running macOS 13. I'll try
now on my M1 and M2.
-- Kevin
On 1/12/2024 5:48 AM, Johan Vos wrote:
Hi Kevin,
Thanks for testing.
With the latest version of the PR, all tests should pass on all
platforms (I believe the PR is ready now). Excluding my last commit,
the tests should fail on all platforms. However, they pass for me (and
Martin) on M2, because the app does not get activated.
- Johan
On Fri, Jan 12, 2024 at 1:53 PM Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
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
