Hi Sergey, Thank you for the review. Actually deliverMoveResizeEvent() is always called once a window is displayed. If the window is created using max W/H of the screen, the function will be invoked and isZoomed field will contain the correct value. I have just checked that.
Thanks, Dmitry > On 23 Mar 2017, at 16:36, Sergey Bylokhov <[email protected]> wrote: > > Hi, Dmitry. > Can you please check that the fix does not break the situation when the frame > is created using max W/H of the screen. In this case the old zoom logic > return true, is it possible that the new logic will return false since > deliverMoveResizeEvent > will not be called? > >> >> >> Hello, >> >> Could you review a fix for jdk9, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8176490 >> webrev: http://cr.openjdk.java.net/~dmarkov/8176490/webrev.00/ >> >> Problem description: >> On OSX AppKit thread and EDT or main application thread might be blocked >> when a child window is displayed and its parent is hidden at the same time. >> AppKit thread performs windows ordering caused by displaying of the child >> window. It retrieves child windows for the parent window and tries to >> acquire the monitor inside Window.getOwnedWindows_NoClientCode(). However >> the monitor is already owned by EDT/main application thread which executes >> setVisible(false) on the parent window. That thread hangs on invocation of >> CWrapper.NSWindow.isZoomed() since the function must be executed on AppKit >> thread. >> >> Fix: >> Add a new field isZoomed to CPlatformWindow class. The field will contain >> information about current zoom state for the window. The method >> deliverMoveResizeEvent() will update the new field using data from the >> platform. The invocations of CWrapper.NSWindow.isZoomed() in CPlatformWindow >> should be replaced with isZoomed field. >> >> Note: I ran JCK tests on the build with fix and did not observe any new >> problems. >> >> Thanks, >> Dmitry >
