Hi Sergey,

There is one other factor needed to explain the zombie color panel: The program 
is leaving behind stale window data, specifically, descriptions of windows that 
were closed prior to the termination of the program. The cause of this stale 
data is that AWT does not terminate the NSApplication that it created. When the 
NSApplication is terminated, it deletes the window data if there are no open 
windows.

The failure to terminate the NSApplication has not been a problem in general 
because AWT windows are not capable of being restored in a new process, but 
NSColorPanel is. I have now seen this problem in my own (bundled) application, 
which allows the user to bring up a color panel. The only observable flaw for 
most AWT applications is the saved state directories left behind. In the 
future, however, AWT windows could be given the ability to be recreated in a 
new process. That, and the possibility that NSApplication might do more cleanup 
in future macOS releases, would argue for fixing this problem.

The solution is to invoke [NSApp terminate], but that is tricky because it also 
terminates the process (it does not return).

My recommendation is to put this test on the problem list until the 
NSApplication problem is solved.

Regards,

  Alan





> On Apr 10, 2018, at 11:39 AM, Alan Snyder <javali...@cbfiddle.com> wrote:
> 
> 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
>  
> <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 
>> <mailto: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 
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8194327>
>>>>> Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ 
>>>>> <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.
> 

Reply via email to