Hi AWT team,
I used the next test to reproduce the problem
===== OwnedWindowTest.java ======
public class OwnedWindowTest {
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
final JFrame jFrame = new JFrame("Owner frame");
jFrame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
jFrame.setSize(new Dimension(500,500));
final JDialog jDialog = new JDialog(jFrame, "Owned dialog",
false);
jDialog.setSize(new Dimension(200,200));
jFrame.setVisible(true);
jDialog.setVisible(true);
}
});
}
}
======== End of OwnedWindowTest.java ======
My configuration:
Hardware Overview:
Model Name: MacBook Pro
Model Identifier: MacBookPro10,2
Processor Name: Intel Core i5
Processor Speed: 2,6 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 3 MB
Memory: 8 GB
Boot ROM Version: MBP102.0106.B0A
SMC Version (system): 2.6f59
Sudden Motion Sensor:
State: Enabled
OS El Capitan
Version 10.11.4
External Display:
Apple Thunderbolt Display
27-inch (2560 x 1440)
Intel HD Graphics 4000 1536 MB graphics
Thank you,
Denis.
On Wed, May 4, 2016 at 4:26 PM, Denis Fokin <denis.fo...@gmail.com> wrote:
> Hi AWT team,
>
> thank you for the great effort in resolving the issue.
>
> I tried the fix (webrev.02) with the latest jdk8u-dev repository.
>
> I have found the next regressions:
>
> 1. Run a test case. JFrame + owned JDialog. Move the frame to the
> secondary monitor. Move the dialog to the main dialog. Click on the frame
> title. Press and hold dialog title. The dialog jumps on the secondary
> screen. Release the mouse button. The dialog jumps to the main screen.
>
> 2. Sometimes, the dialog does not return back to the secondary screen.
>
> 3. I do not remember exact scenario, but once, the dialog became minified
> (folded into title).
>
>
> It looks like the fix require further improvement.
>
> I personally, do not like all these add/remove machinery. Keeping z-order
> model in awt and placing all windows in the NSNormalWindowLevel
> level seems the best solution to me. Otherwise, we will get constant
> regressions.
>
> Thank you,
> Denis.
>
>
> On Thu, Apr 28, 2016 at 4:24 PM, dmitry markov <dmitry.mar...@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
>>
>> 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()
>>
>> 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.mar...@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/
>>
>> 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.mar...@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/
>>
>> 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
>>
>>
>>
>>
>>
>
