Hi Sergey, I can use System Preferences instead of Finder to avoid problems with pre-existing windows and utility panels covering the test frames.
I have also experienced the color panel reappearing in applications run using the java command. I notice there is a directory ~/Library/Saved Application State/net.java.openjdk/cmd.savedState, which contains information about windows, including the color panel and the Java frames that were closed. I do not know how to prevent the color panel from reopening, other than by disabling this feature for the java command. See: https://apple.stackexchange.com/questions/177428/how-to-prevent-one-app-from-saving-restoring-any-saved-state It seems to me that saving information for the java command is a mistake, as it is an application launcher, not a single application. Perhaps the JDK installer should disable this feature. Alan > On Apr 9, 2018, at 4:06 PM, Sergey Bylokhov <sergey.bylok...@oracle.com> > wrote: > > Hi, Alan. > I just found a few side effects in the test. > - All other tests(actually all java applications) which are executed after > the new test will show colorPanel(until it will not be closed manually). > - If the Finder will be opened in full screen(or in the location where the > test will show the test windows) then the test will fail. Maybe it is better > to use some other application to deactivate the test? Can we implement it > using other java application?(you can run the same TestMainKeyWindow.main() > and pass some flag to it) > > > On 05/04/2018 16:15, Alan Snyder wrote: >> Thank you for your comments. Here is the updated webrev: >> http://cr.openjdk.java.net/~serb/alans/8194327/webrev.01/ >> <http://cr.openjdk.java.net/~serb/alans/8194327/webrev.01/> >> Alan >>> On Apr 4, 2018, at 9:34 AM, Sergey Bylokhov <sergey.bylok...@oracle.com >>> <mailto:sergey.bylok...@oracle.com> <mailto:sergey.bylok...@oracle.com >>> <mailto:sergey.bylok...@oracle.com>>> wrote: >>> >>> Hi, Alan. >>> A few comments about the test: >>> - It is a mac specific and JtregNativeJdk should compile it on mac only >>> - It should close all windows at the end, currently it leaves Finder opened. >>> - it tries to use NSWindowStyleMask/NSWindowStyleMaskTitled which are >>> available in >10.12. We only plan to move to 10.9 soon. So the test should >>> skip it or use NSInteger/NSTitledWindowMask for macOS < >>> MAC_OS_X_VERSION_10_12. >>> - It looks like other tests in JtregNativeJdk.gmk use libtest+Some useful >>> name, I suggest to use the same instead of bugid(same for the test name >>> "Test.java"). >>> BUILD_JDK_JTREG_LIBRARIES_LIBS_libtest819432 >>> >>> On 02/04/2018 19:35, Alan Snyder wrote: >>>> Please review the following change to the macOS AWT. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 >>>> Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ >>>> The goal of this change is to allow a Java desktop application on macOS to >>>> properly coexist with a native utility panel, such as the native color >>>> chooser. >>>> The native color chooser is an example of a window that can become the key >>>> (focused) window but cannot become the main window. >>>> If the previously active window is a Java frame, it should resign key >>>> window status (lose focus), but retain the main window status. >>>> A window that is main but not key does not own the keyboard focus, but it >>>> appears active, and if it is using the screen menu bar, >>>> it may be invoked to process a menu item action (if the menu item is not >>>> already handled by the key window). >>>> The current macOS AWT does not support this combination of window states. >>>> A Java window is either key and main, or neither. >>>> When the color chooser becomes key (obtains focus), the Java frame resigns >>>> both key and main status. >>>> This change allows the key window status to be resigned while retaining >>>> the main window status, with the appropriate behavior. >>>> Note that with this change, it remains impossible to implement a Java >>>> window that behaves like the native color chooser (i.e., can become key >>>> but not main). >>>> That would require a much bigger change. >>>> Alan >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey.
