[External] : Re: MacOS windowDidBecomeKey inconsistency
Kevin Rushforth
kevin.rushforth at oracle.com
Fri Jan 12 16:25:09 UTC 2024
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.rushforth at 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.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/c98900de/attachment-0001.htm>
More information about the openjfx-dev
mailing list