[External] : Re: MacOS windowDidBecomeKey inconsistency
Kevin Rushforth
kevin.rushforth at oracle.com
Fri Jan 12 15:17:44 UTC 2024
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.rushforth at 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_fox at 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.rushforth at 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_fox at 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.vos at 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
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240112/431d9c3f/attachment-0001.htm>
More information about the openjfx-dev
mailing list