[External] : Re: MacOS windowDidBecomeKey inconsistency

Fri Jan 12 12:52:52 UTC 2024

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/3e5e9182/attachment-0001.htm>