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
