<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
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 class="moz-cite-prefix">On 1/12/2024 5:56 AM, Kevin Rushforth
wrote:<br>
</div>
<blockquote type="cite" cite="mid:05804f0a-fce7-4100-aa87-8cfbeac7a313@oracle.com">
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 class="moz-cite-prefix">On 1/12/2024 5:48 AM, Johan Vos
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABxFH2G73AOMAo7RQP+3qDg6ojA5mH9rns0HABY0KpHp4fn40w@mail.gmail.com">
<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" 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>
</body>
</html>