RFR: 8296972: [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected.

[Harshitha Onkar]

On Wed, 7 Jun 2023 20:13:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes more time on macOS 13 than on previous macOS version. So the test failure is triggered by the lack of synchronisation.
>> When you added displayChanged() call you introduced some kind of delay and the problem stopped happening but it is still present. I do not think any changes are required in JDK but the test definitely needs some modifications. 
>> In particular I believe the test must check the state of the frame only when the corresponding `window state changed` event is received.
>
>> If I got it right the switching to `ICONIFIED`/`MAXIMIZED_BOTH` state takes more time on macOS 13 than on previous macOS version. So the test failure is triggered by the lack of synchronisation. When you added displayChanged() call you introduced some kind of delay and the problem stopped happening but it is still present. I do not think any changes are required in JDK but the test definitely needs some modifications. In particular I believe the test must check the state of the frame only when the corresponding `window state changed` event is received.
> 
> I did some testing and I think that without the delay, when the frame moves from iconified to maximized states, the second windowStateChanged event never comes (first being iconified -> normal, second being normal -> maximized), so the test will not pass even if we only check state of the frame on a windowStateChanged event. 
> 
> Why do you think no changes are required in the JDK? Shouldn't there be some synchronization needed when calling the native deminiaturize and maximize functions in CPlatformWindow?

@alisenchung @mrserb 

After reading through the discussion, I think the fix on native side rather than on Java might work better here. I was revisiting a Tray Icon issue which had similar sync problem when I was trying to get updated scale value on Java side by using a DisplayChangedListener [Details here - [PR#8441](https://github.com/openjdk/jdk/pull/8441#issuecomment-1121345834)] and there were multiple events occurring back to back. When I had a hard-coded delay set on Java side, the update to tray icon worked fine. I think this is a similar case where introducing a delay solves the issue. But since hard-coded delay is not the ideal solution probably triggering/ calling the required piece of code after everything is updated on native side is the way to go (event/message-driven).

Handling the code on Window's native code with the help of windows messaging event solved the Trayicon problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1581538514