<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
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>
</body>
</html>