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
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/
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
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
Jen
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,
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
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 alrea
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), bu
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'
I should add that the inconsistency only happens when running the
systemtests using Gradle.
When I isolate the failing systemtest and run it as a Java process, it
correctly fails on both M2 and Mac/Intel.
At this point, I don't have enough information to create a JBS issue
though. I added debug in
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 we
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 `wi
12 matches
Mail list logo
