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 Before digging deeper on Cocoa Event Handling, please check if fixing on native side by waiting for an approriate NSEvent is a viable solution in this case. 

A gist of Cocoa Event Handling mechanism - 

1. NSRunLoop in the event loop [NSApplicationAWT.m#L303](https://github.com/openjdk/jdk/blob/ea41907396a70933c4f6e6b0f247f7ba589a3a23/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L303) handled by NSApp. 
2. NSApp converts this event into NSEvent object and dispatches using sendEvent to the appropriate NSView object.

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

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