<AWT Dev> [9] Review request for 8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus

dmitry markov dmitry.markov at oracle.com
Fri Apr 29 07:32:53 UTC 2016

Thank you for the review.

Can anyone else review the fix, please?

On 29/04/2016 10:25, Anton Tarasov wrote:
> On 29 Apr 2016, at 09:50, dmitry markov <dmitry.markov at oracle.com 
> <mailto:dmitry.markov at oracle.com>> wrote:
>> The main idea of suggested implementation is to keep 'main/key' 
>> window in normal window level and move all its child windows to 
>> floating level. Such approach guarantees that the child windows will 
>> appear in front of 'main/key' window and 'main/key' window will not 
>> overlap them when it is resized, moved, etc. It is supported by 
>> native OS and requires less changes in our code.
>> Of course we can implement similar logic without usage of floating 
>> window level, but that solution will be quite complex and requires 
>> many changes in the code. In other words we will have to maintain the 
>> correct windows order (child window should be above parent window) by 
>> ourselves after every resize, move and similar operations. Also there 
>> are some scenarios where it is quite difficult or almost impossible 
>> to detect that ordering is required due to native OS limitation.
>> Based on above I believe the usage of floating window level is more 
>> suitable for this case. Also as far as I know Windows OS uses quite 
>> similar window level concept to process parent-child relationship.
> Ok, got it, sounds reasonable to me.
>> On 28/04/2016 17:08, Anton Tarasov wrote:
>>> Ok, thanks for the explanation. My assumption about putting 
>>> "main/key” window to the floating level was wrong.
>>> Can you please clarify the following as well. Why ordering 
>>> everything at a normal level won’t work? For the example below, B & 
>>> C will both appear at the floating level, though they have 
>>> owner/child relationship (that is they will be ordered at the same 
>>> level).
>>>> On 28 Apr 2016, at 16:24, dmitry markov <dmitry.markov at oracle.com 
>>>> <mailto:dmitry.markov at oracle.com>> wrote:
>>>> Anton,
>>>> Let me clarify the implementation of orderChilds() function. It is 
>>>> responsible for proper windows ordering, (i.e. child windows should 
>>>> be always placed/ordered above their parents or owners; a 
>>>> parent/owner window should not overlap its children during sizing 
>>>> or moving operations).
>>>> Usually all Java windows/frames/dialogs have the normal level.
>>>> When a window receives focus, (i.e. becomes 'main/key' window), we 
>>>> will look for all its children and move them to the floating level. 
>>>> According to Cocoa documentation: floating windows always appear in 
>>>> front of normal-level windows, (see 
>>>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/#//apple_ref/occ/instp/NSWindow/level). 
>>>> Also we explicitly order each children above its nearest owner 
>>>> using orderWindow() function, see code fragment below:
>>>> [window orderWindow:NSWindowAbove relativeTo:[owner.nsWindow windowNumber]];
>>>> When a window loses focus, (i.e. resigns 'main/key' window status), 
>>>> we will look for its children and move them back to the normal 
>>>> level. And of course we order each child window above its nearest 
>>>> parent using orderWindow().
>>>> Please note: orderChilds() function changes window level only for 
>>>> child windows of current 'main/key' window, (i.e. focus owner); the 
>>>> window level of 'main/key' is not affected.
>>>> So for your example: A<-B<-C relationship and A,C,B sequence 
>>>> (assume A has just received focus) we will get something following:
>>>> 1. A stays at the normal window level
>>>> 2. C is moved to the floating level and ordered above B
>>>> 3. B is moved to the floating level and ordered above A (actually 
>>>> ordering operation does not matter here since A and B are located 
>>>> at different levels)
>>>> 4. C and B are displayed in front of A due to different window 
>>>> levels; C is appeared above B due to ordering call at step 2
>>> Is it true that reordering B still keeps C above it? If so, then the 
>>> scheme works.
>> Frankly I am not sure about this. I performed several tests with 
>> various numbers of child windows and their sequences. I was not able 
>> to reproduce the situation when child window is appeared behind its 
>> parent. So if you have any test case for this, please let me know and 
>> I will look into it.
>> Anyway I think this case is outside the scope of the fix and should 
>> be investigated under separate bug, if any.
> I don’t have any contra-scenarious at the moment, so let's rely on 
> your testing results then…
> Thanks!
> Anton.
>> Thanks,
>> Dmitry
>>>> I agree the comments inside orderChilds() are not clear and may 
>>>> confuse. I updated the fix, new version is located at 
>>>> http://cr.openjdk.java.net/~dmarkov/8080729/webrev.02/
>>>> Summary of change:
>>>> - Renamed orderChilds() and iconifyChilds() to orderChildWindows() 
>>>> and iconifyChildWindows() accordingly
>>>> - Added some comments to orderChildWindows()
>>> Ok, looks fine to me.
>>> Regards
>>> Anton.
>>>> Thanks,
>>>> Dmitry
>>>> On 28/04/2016 11:40, Anton Tarasov wrote:
>>>>> Hi Dmitry,
>>>>> Honestly, I don’t clearly understand how it works now.
>>>>> With A<-B<-C relationship and A,C,B sequence:
>>>>> 1. C is ordered above B (we get: A-C-B)
>>>>> 2. B is ordered above A (we get: B-A-C)
>>>>> So, C ordering is lost. Or I'm missing something?
>>>>> Also, can you please clarify the following.
>>>>> +                    if (focus) {
>>>>> +                        // Place the child above the owner
>>>>> +                        [window setLevel:NSFloatingWindowLevel];
>>>>> +                    } else {
>>>>> +                        // Place the child to the owner's level
>>>>> +                        [window setLevel:NSNormalWindowLevel];
>>>>> +                    }
>>>>> Am I right that the reason you place the child to the floating 
>>>>> level is because the “main/key” window is there? If so, then the 
>>>>> comment is somewhat confusing. You don’t really put the child 
>>>>> above the owner with that call. With both the calls you simply put 
>>>>> the child to the owner’s level. Is that correct?
>>>>> And also, if you modify the code further, may be you rename 
>>>>> “Childs” in the new methods to “Children” or to “ChildWindows”?
>>>>> Thanks,
>>>>> Anton.
>>>>>> On 28 Apr 2016, at 10:06, dmitry markov <dmitry.markov at oracle.com 
>>>>>> <mailto:dmitry.markov at oracle.com>> wrote:
>>>>>> Hi Anton,
>>>>>> Thank you for your feedback. You are right, in some cases B may 
>>>>>> be ordered above C and that is incorrect. I have updated the fix 
>>>>>> to eliminate this. Now we order a window above its nearest 
>>>>>> parent/owner, (i.e. B is ordered above A, C is ordered above B).
>>>>>> Please find new version here: 
>>>>>> http://cr.openjdk.java.net/~dmarkov/8080729/webrev.01/ 
>>>>>> <http://cr.openjdk.java.net/%7Edmarkov/8080729/webrev.01/>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>> On 27/04/2016 13:46, Anton Tarasov wrote:
>>>>>>> Hi Dmitry,
>>>>>>> The fix looks fine to me, still I have some concern...
>>>>>>> Say, we have windows with the following relationship: A<-B<-C 
>>>>>>> (owner<-child). Then the ordering is executed for A:
>>>>>>> - We’ve got a sequence: A, B, C.
>>>>>>> - A is skipped, B is ordered above A, C is ordered above A
>>>>>>> Am I right that C will be ordered above B (as it should be) 
>>>>>>> eventually?
>>>>>>> Is that possible that we get a sequence: A, C, B? And then B 
>>>>>>> will be ordered above C which is incorrect?
>>>>>>> Thanks,
>>>>>>> Anton.
>>>>>>>> On 25 Apr 2016, at 22:35, dmitry markov 
>>>>>>>> <dmitry.markov at oracle.com <mailto:dmitry.markov at oracle.com>> wrote:
>>>>>>>> Any volunteers to review the fix?
>>>>>>>> Thanks in advance,
>>>>>>>> Dmitry
>>>>>>>> On 21/04/2016 10:21, dmitry markov wrote:
>>>>>>>>> Hello,
>>>>>>>>> Could you review the fix for jdk9, please?
>>>>>>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8080729
>>>>>>>>>    webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8080729/webrev.00/ 
>>>>>>>>> <http://cr.openjdk.java.net/%7Edmarkov/8080729/webrev.00/>
>>>>>>>>> Problem description:
>>>>>>>>> On OS X platform in dual monitor setup a child window jumps to 
>>>>>>>>> another monitor where a parent/owner is displayed.
>>>>>>>>> In CPlatformWindow and CWarningWindow classes we use 
>>>>>>>>> CWrapper.NSWindow.addChildWindow() and 
>>>>>>>>> CWrapper.NSWindow.removeChildWindow() during parent-child 
>>>>>>>>> relationship processing (see setVisible() and 
>>>>>>>>> orderAboveSiblings() for details). The methods 
>>>>>>>>> addChildWindow() and removeChildWindow() invoke corresponding 
>>>>>>>>> Cocoa API (see NSWindow in Cocoa framework). According to 
>>>>>>>>> Cocoa documentation:
>>>>>>>>> "After a window is added as a child of parent window, it is 
>>>>>>>>> maintained in relative position indicated by ordering mode for 
>>>>>>>>> subsequent ordering operations involving either window. While 
>>>>>>>>> this attachment is active, moving child window will not cause 
>>>>>>>>> parent window to move, but moving the parent window will cause 
>>>>>>>>> child window to move."
>>>>>>>>> So negative visual effects such as jumping to another monitor 
>>>>>>>>> in multi-monitor case, etc. are caused by usage of 
>>>>>>>>> addChildWindow() and removeChildWindow().
>>>>>>>>> Fix:
>>>>>>>>> Replace CWrapper.NSWindow.addChildWindow() and 
>>>>>>>>> CWrapper.NSWindow.removeChildWindow() calls with 
>>>>>>>>> CWrapper.NSWindow.orderWindow() in CPlatformWindow and 
>>>>>>>>> CWarningWindow classes.
>>>>>>>>> Add several new methods to AWTWindow.m:
>>>>>>>>> - iconifyChilds() is responsible for hiding or showing child 
>>>>>>>>> windows when parent/owner window is miniaturized or 
>>>>>>>>> de-miniaturized.
>>>>>>>>> - orderChilds() is responsible for child windows ordering. 
>>>>>>>>> Order operation is based on the current focus state of owner 
>>>>>>>>> window, (e.g. if owner window is focused, all its child should 
>>>>>>>>> be ordered above it).
>>>>>>>>> - isJavaPlatformWindowVisible() checks visibility of native 
>>>>>>>>> window from Java layer perspective.
>>>>>>>>> Thanks,
>>>>>>>>> Dmitry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160429/b3036177/attachment-0001.html>

More information about the awt-dev mailing list