Interesting. I reran our headful test job after updating to macOS 14.2.1
and it didn't make a difference -- the SystemMenuBarTest passes on both
the Intel and M2 systems. Not sure what to make of this, but you might
be right about there being an aspect of this that's timing related.
I can take a closer look next week.
-- Kevin
On 1/12/2024 2:04 PM, Martin Fox wrote:
I think this is related to event ordering/timing. On my M2 Studio
running 14.2.1 the test app still failed to activate. Well, unless I
rebooted my system. In that case it activated only on the first test
run. From there on out it failed to activate.
I’m seeing a puzzling difference. If I run an app from the command
line the [NSApp activate] call occurs before the window is made
visible but from Gradle it occurs after. To get the app to
consistently activate when run from Gradle I had to add
windowDidChangeScreen to the delegate and call [NSApp activate] from
there. This moves the activation call to an earlier point when we run
from Gradle but to a later point when running a JavaFX app directly.
In any case I don’t think this is an issue with cooperative
activation, it seems a Gradle run changes the order of events in a
surprising way that can interfere with activation. Sometimes.
Martin
On Jan 12, 2024, at 8:25 AM, Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
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:
https://bugs.openjdk.org/browse/JDK-8320056
https://bugs.openjdk.org/browse/JDK-8320057
https://bugs.openjdk.org/browse/JDK-8320110
https://bugs.openjdk.org/browse/JDK-8320111
I'll report back after our two Jenkins systems are upgraded to macOS
14.2.1.
-- Kevin
On 1/12/2024 7:57 AM, Johan Vos wrote:
I updated (my M2) from 14.1 to 14.2.1 and now the test correctly
fails (after reverting my last commit).
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).
- Johan
On Fri, Jan 12, 2024 at 4:18 PM Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
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:
Local systems:
Intel MacBook macOS 13.6.3 -- test failed
M1 MacBook macOS 14.2.1 -- test failed
Jenkins CI systems:
Intel MacBook macOS 13.x -- test failed
Intel MacBook macOS 14.1 (*) -- test PASSED
M2 MacBook macOS 13.x -- test failed
M2 MacBook macOS 14.0 (*) -- test PASSED
(*) Note the downrev version of Sonoma
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?
-- Kevin
On 1/12/2024 5:56 AM, Kevin Rushforth wrote:
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.
-- Kevin
On 1/12/2024 5:48 AM, Johan Vos wrote:
Hi Kevin,
Thanks for testing.
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.
- Johan
On Fri, Jan 12, 2024 at 1:53 PM Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
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.
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.
-- Kevin
On 1/12/2024 12:40 AM, Johan Vos wrote:
Hi Martin,
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).
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.
- Johan
On Thu, Jan 11, 2024 at 6:18 PM Martin Fox
<m_r_...@sbcglobal.net> wrote:
Johan,
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).
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.
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.
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.
Martin
On Jan 11, 2024, at 5:40 AM, Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
Hi Johan,
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.
-- Kevin
On 1/11/2024 12:08 AM, Johan Vos wrote:
Hi Martin,
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.
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!
- Johan
On Wed, Jan 10, 2024 at 7:58 PM Martin Fox
<m_r_...@sbcglobal.net> wrote:
Johan,
Are you referring to PR 1283? And are you
seeing test failures on Intel or M2?
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.
Martin
On Jan 10, 2024, at 2:10 AM, Johan Vos
<johan....@gluonhq.com> wrote:
I noticed different test results when running
systemtests on a mac/intel versus an M2.
when running systemtests from a command line
using
`sh gradlew --info -PFULL_TEST=true
:systemTests:cleanTest :systemTests:test
--tests=test.com.sun.javafx.tk.quantum.SystemMenuBarTest`
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.
I wonder if this is somehow related to
https://bugs.openjdk.org/browse/JDK-8089848.
Before looking into this, is this something
others observed as well?
- Johan
