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