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