Hi Sergey, As per your suggestion, I have reverted the fix to original state, before the fix of initial bug (code before fix of issue JDK-7158623 with change set e0b025915be8). The MAXIMIZED_BOTH frame is now resizable on Mac OS, which is the default behaviour on Mac OS. The test case is modified to escape execution on Mac OS. Please review the update webrev:
http://cr.openjdk.java.net/~mhalder/8215280/webrev.02/ <http://cr.openjdk.java.net/~mhalder/8215280/webrev.02/> Regards, Manajit > On 09-Jan-2019, at 3:35 AM, Sergey Bylokhov <[email protected]> > wrote: > > Hi, Manajit. > Why did you drop this check "&& !isMaximizedBoth();" from the > setResizable(resizable)? This change is necessary to fix the bug? > > BTW I have started to feel that probably we should not fix initial bug at all > and leave it as is, and by default use the native cocoa behavior > > On 07/01/2019 01:57, Manajit Halder wrote: >> Hi Sergey, >> You are right. I have changed the code to reset the resizable behaviour in >> NORMAL state. Please review the webrev: >> http://cr.openjdk.java.net/~mhalder/8215280/webrev.01/ >> Regards, >> Manajit >>> On 05-Jan-2019, at 3:54 AM, Sergey Bylokhov <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi, Manajit.> The fix makes sure a frame after transition due to double >>> click on title bar from MAXIMIZED_BOTH state to NORMAL state is resizable. >>> I guess the frame in the NORMAL state should be resizable if it was >>> resizable before MAXIMIZED_BOTH, but if the user set it to non-resizable >>> before MAXIMIZED_BOTH then the frame should be non-resizable in a NORMAL >>> state. Can you check this case, please? >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey.
