<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">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"><u></u>
<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">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">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">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">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">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>