<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
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">https://bugs.openjdk.org/browse/JDK-8320056</a><br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8320057">https://bugs.openjdk.org/browse/JDK-8320057</a><br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8320110">https://bugs.openjdk.org/browse/JDK-8320110</a><br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8320111">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>
</body>
</html>