<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Interesting. I reran our headful test job after updating to macOS
14.2.1 and it didn't make a difference -- the SystemMenuBarTest
passes on both the Intel and M2 systems. Not sure what to make of
this, but you might be right about there being an aspect of this
that's timing related.<br>
<br>
I can take a closer look next week.<br>
<br>
-- Kevin<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/12/2024 2:04 PM, Martin Fox wrote:<br>
</div>
<blockquote type="cite" cite="mid:A97DC37E-D25C-413A-9D03-40E4EDC486DD@sbcglobal.net">
I think this is related to event ordering/timing. On my M2 Studio
running 14.2.1 the test app still failed to activate. Well, unless
I rebooted my system. In that case it activated only on the first
test run. From there on out it failed to activate.
<div><br>
</div>
<div>I’m seeing a puzzling difference. If I run an app from the
command line the [NSApp activate] call occurs before the window
is made visible but from Gradle it occurs after. To get the app
to consistently activate when run from Gradle I had to add
windowDidChangeScreen to the delegate and call [NSApp activate]
from there. This moves the activation call to an earlier point
when we run from Gradle but to a later point when running a
JavaFX app directly.</div>
<div><br>
</div>
<div>In any case I don’t think this is an issue with cooperative
activation, it seems a Gradle run changes the order of events in
a surprising way that can interfere with activation. Sometimes.</div>
<div><br>
</div>
<div>Martin</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Jan 12, 2024, at 8:25 AM, Kevin Rushforth
<a class="moz-txt-link-rfc2396E" href="mailto:kevin.rushforth@oracle.com"><kevin.rushforth@oracle.com></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div> So that does strongly suggest that this was an OS
bug on earlier macOS 14.0.x and 14.1.x now fixed in
14.2. FYI, here are four Swing / AWT bugs that point to
problems with native events, all of which are fixed in
macOS 14.2:<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8320056" moz-do-not-send="true">https://bugs.openjdk.org/browse/JDK-8320056</a><br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8320057" moz-do-not-send="true">https://bugs.openjdk.org/browse/JDK-8320057</a><br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8320110" moz-do-not-send="true">https://bugs.openjdk.org/browse/JDK-8320110</a><br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8320111" moz-do-not-send="true">https://bugs.openjdk.org/browse/JDK-8320111</a><br>
<br>
I'll report back after our two Jenkins systems are
upgraded to macOS 14.2.1.<br>
<br>
-- Kevin<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/12/2024 7:57 AM, Johan
Vos wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABxFH2ESPtDGe=LVYg26NsjkHbOfGOuT3DVM=2TtquO5L9GGQg@mail.gmail.com">
<div dir="ltr">I updated (my M2) from 14.1 to 14.2.1
and now the test correctly fails (after reverting my
last commit).
<div>Since it passed before (14.1) and failed after
(14.2.1) updating, it is indeed more likely to be
related to OS version rather than CPU arch (which
I would find very weird).</div>
<div><br>
</div>
<div>- Johan</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jan 12,
2024 at 4:18 PM Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">kevin.rushforth@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> I ran the version of your fix+test from
before yesterday's fix. It fails on most of the
systems (meaning the window was activated), but
passes unexpectedly on two of them, one Intel
and one M2:<br>
<br>
Local systems:<br>
<br>
Intel MacBook macOS 13.6.3 -- test failed<br>
M1 MacBook macOS 14.2.1 -- test failed<br>
<br>
Jenkins CI systems:<br>
<br>
Intel MacBook macOS 13.x -- test failed<br>
Intel MacBook macOS 14.1 (*) -- test PASSED<br>
M2 MacBook macOS 13.x -- test failed<br>
M2 MacBook macOS 14.0 (*) -- test PASSED<br>
<br>
(*) Note the downrev version of Sonoma<br>
<br>
We know that Apple has fixed several OS bugs in
14.2, so I am going to get our lab systems
updated to that version (I thought they were
already running 14.2[.1] and don't want to be
chasing down problems that turn out to be
related to running an older version than
expected). In the mean time, can you check the
versions of the OS on your M1 and M2 systems?<br>
<br>
-- Kevin<br>
<br>
<br>
<div>On 1/12/2024 5:56 AM, Kevin Rushforth
wrote:<br>
</div>
<blockquote type="cite"> 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.<br>
<br>
-- Kevin<br>
<br>
<div>On 1/12/2024 5:48 AM, Johan Vos wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Kevin,
<div><br>
</div>
<div>Thanks for testing. </div>
<div>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.</div>
<div><br>
</div>
<div>- Johan</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri,
Jan 12, 2024 at 1:53 PM Kevin Rushforth
<<a href="mailto:kevin.rushforth@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">kevin.rushforth@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> 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.<br>
<br>
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.<br>
<br>
-- Kevin<br>
<br>
<br>
<div>On 1/12/2024 12:40 AM, Johan Vos
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Martin,
<div><br>
</div>
<div>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).</div>
<div>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.</div>
<div><br>
</div>
<div>- Johan</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On
Thu, Jan 11, 2024 at 6:18 PM
Martin Fox <<a href="mailto:m_r_fox@sbcglobal.net" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">m_r_fox@sbcglobal.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Johan,
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Martin</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Jan 11, 2024, at
5:40 AM, Kevin
Rushforth <<a href="mailto:kevin.rushforth@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">kevin.rushforth@oracle.com</a>>
wrote:</div>
<br>
<div>
<div> Hi Johan,<br>
<br>
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.<br>
<br>
-- Kevin<br>
<br>
<br>
<div>On 1/11/2024
12:08 AM, Johan
Vos wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi
Martin,
<div><br>
</div>
<div>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.</div>
<div>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!</div>
<div><br>
</div>
<div>- Johan</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jan 10, 2024 at 7:58 PM Martin Fox <<a href="mailto:m_r_fox@sbcglobal.net" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">m_r_fox@sbcglobal.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Johan,
<div><br>
</div>
<div>Are you
referring to
PR 1283? And
are you seeing
test failures
on Intel or
M2?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Martin</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Jan
10, 2024, at
2:10 AM, Johan
Vos <<a href="mailto:johan.vos@gluonhq.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">johan.vos@gluonhq.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>I noticed
different test
results when
running
systemtests on
a mac/intel
versus an M2.</div>
<div>when
running
systemtests
from a command
line using </div>
<div><br>
</div>
<div>`sh
gradlew --info
-PFULL_TEST=true :systemTests:cleanTest :systemTests:test
--tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest`</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
I wonder if
this is
somehow
related to <a href="https://bugs.openjdk.org/browse/JDK-8089848" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8089848</a>.
Before looking
into this, is
this something
others
observed as
well?<br>
<div><br>
</div>
<div>- Johan</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>