<AWT Dev> RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors

Wed Apr 18 01:36:16 UTC 2018

On 16/04/2018 18:25, Alan Snyder wrote:
> 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. 

I suggest you to create a separate CR for this bug for tracking.

> 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.

It is strange that it is visible only in case of color_panel, maybe it 
is possible to simplify the testcase and replace color_panel by some 
other NSWIndow?

> 
> 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 <javalists at cbfiddle.com 
>> <mailto:javalists at 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
>>
>> 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.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at 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/
>>>> Alan
>>>>> On Apr 4, 2018, at 9:34 AM, Sergey Bylokhov 
>>>>> <Sergey.Bylokhov at oracle.com 
>>>>> <mailto:Sergey.Bylokhov at oracle.com><mailto:Sergey.Bylokhov at 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.
>>
> 

-- 
Best regards, Sergey.