Re: AWT Dev [8] Review request for 7124376: [macosx] Modal dialog lost focus
Hi, Leonid, I wonder why you need this check for *_EXCLUDED in platform code? Whether a window should be blocked or not is determined at the shared level, in java.awt.Window/Dialog, so it's either bug in this shared code, or the check in CPlatformWindow is redundant. Thanks, Artem On 5/2/2012 11:10 PM, Leonid Romanov wrote: Hi, I've reworked my fix. See http://cr.openjdk.java.net/~leonidr/7124376/webrev.01/ On 27.04.2012, at 22:04, Anthony Petrov wrote: I've noticed that too. I didn't point this out though, because you're also checking the MODAL_EXCLUDED flag in your modallyBlocked(), so I thought it was OK. But if you can pull this check to the Java code before even calling modallyBLocked(), then I guess the setEnabled name would make more sense. -- best regards, Anthony On 4/27/2012 10:02 PM, Leonid Romanov wrote: I've looked at 7124395 and the fixes you did for FX and it looks like we need setEnabled method for AWTWindow. I'll redo my fix accordingly. On 27.04.2012, at 21:39, Anthony Petrov wrote: Hi Leonid, I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. Regarding the fix itself: 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? -- best regards, Anthony On 4/27/2012 6:11 PM, Leonid Romanov wrote: Hi, Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking Show Message Dialog button. Now, click on the SwingSet2 window title bar and you'll see the window rapidly gaining and loosing focus. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ Thanks, Leonid.
AWT Dev [8] Review request for 7124376: [macosx] Modal dialog lost focus
Hi, Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking Show Message Dialog button. Now, click on the SwingSet2 window title bar and you'll see the window rapidly gaining and loosing focus. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ Thanks, Leonid.
Re: AWT Dev [8] Review request for 7124376: [macosx] Modal dialog lost focus
Hi Leonid, I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. Regarding the fix itself: 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? -- best regards, Anthony On 4/27/2012 6:11 PM, Leonid Romanov wrote: Hi, Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking Show Message Dialog button. Now, click on the SwingSet2 window title bar and you'll see the window rapidly gaining and loosing focus. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ Thanks, Leonid.
Re: AWT Dev [8] Review request for 7124376: [macosx] Modal dialog lost focus
Hi, 1. Yep, I've verified whether my solution works for AWT and indeed it does: returning NO from canBecomeMain/KeyWindow does prevent OS from bringing window to the front. Wonder why it doesn't work for FX. The thing is, if we allow OS to bring blocked window to the front, even for a fraction of second required to restack window back, then user would see window jumping forth and back in z-order, and this is something we want to avoid. 2. I need to check on this. Thanks for pointing it out. Leonid. On 27.04.2012, at 21:39, Anthony Petrov wrote: Hi Leonid, I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. Regarding the fix itself: 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? -- best regards, Anthony On 4/27/2012 6:11 PM, Leonid Romanov wrote: Hi, Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking Show Message Dialog button. Now, click on the SwingSet2 window title bar and you'll see the window rapidly gaining and loosing focus. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ Thanks, Leonid.
Re: AWT Dev [8] Review request for 7124376: [macosx] Modal dialog lost focus
On 4/27/2012 9:53 PM, Leonid Romanov wrote: 1. Yep, I've verified whether my solution works for AWT and indeed it does: returning NO from canBecomeMain/KeyWindow does prevent OS from bringing window to the front. Wonder why it doesn't work for FX. The thing is, if we allow OS to bring blocked window to the front, even for a fraction of second required to restack window back, then user would see window jumping forth and back in z-order, and this is something we want to avoid. Please try clicking the title-bar of a blocked window, not its content area. Does it still not jump to the front? Perhaps Apple fixed this in 10.7, but on my old 10.6.8 system the canBecome-NO windows did go to the top of the stacking order when being clicked. Note that the restacking is unnoticed since in FX it's performed during the windowDidBecomeKey event processing. If we postpone this operation, then indeed, some flickering will be visible. -- best regards, Anthony 2. I need to check on this. Thanks for pointing it out. Leonid. On 27.04.2012, at 21:39, Anthony Petrov wrote: Hi Leonid, I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. Regarding the fix itself: 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? -- best regards, Anthony On 4/27/2012 6:11 PM, Leonid Romanov wrote: Hi, Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking Show Message Dialog button. Now, click on the SwingSet2 window title bar and you'll see the window rapidly gaining and loosing focus. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ Thanks, Leonid.
Re: AWT Dev [8] Review request for 7124376: [macosx] Modal dialog lost focus
I've noticed that too. I didn't point this out though, because you're also checking the MODAL_EXCLUDED flag in your modallyBlocked(), so I thought it was OK. But if you can pull this check to the Java code before even calling modallyBLocked(), then I guess the setEnabled name would make more sense. -- best regards, Anthony On 4/27/2012 10:02 PM, Leonid Romanov wrote: I've looked at 7124395 and the fixes you did for FX and it looks like we need setEnabled method for AWTWindow. I'll redo my fix accordingly. On 27.04.2012, at 21:39, Anthony Petrov wrote: Hi Leonid, I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. Regarding the fix itself: 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? -- best regards, Anthony On 4/27/2012 6:11 PM, Leonid Romanov wrote: Hi, Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking Show Message Dialog button. Now, click on the SwingSet2 window title bar and you'll see the window rapidly gaining and loosing focus. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ Thanks, Leonid.
Re: AWT Dev [8] Review request for 7124376: [macosx] Modal dialog lost focus
Hmmm… Perhaps we too restack window during windowDidBecomeKey event processing or do something similar. I'll check it tomorrow. On 27.04.2012, at 22:01, Anthony Petrov wrote: On 4/27/2012 9:53 PM, Leonid Romanov wrote: 1. Yep, I've verified whether my solution works for AWT and indeed it does: returning NO from canBecomeMain/KeyWindow does prevent OS from bringing window to the front. Wonder why it doesn't work for FX. The thing is, if we allow OS to bring blocked window to the front, even for a fraction of second required to restack window back, then user would see window jumping forth and back in z-order, and this is something we want to avoid. Please try clicking the title-bar of a blocked window, not its content area. Does it still not jump to the front? Perhaps Apple fixed this in 10.7, but on my old 10.6.8 system the canBecome-NO windows did go to the top of the stacking order when being clicked. Note that the restacking is unnoticed since in FX it's performed during the windowDidBecomeKey event processing. If we postpone this operation, then indeed, some flickering will be visible. -- best regards, Anthony 2. I need to check on this. Thanks for pointing it out. Leonid. On 27.04.2012, at 21:39, Anthony Petrov wrote: Hi Leonid, I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. Regarding the fix itself: 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? -- best regards, Anthony On 4/27/2012 6:11 PM, Leonid Romanov wrote: Hi, Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking Show Message Dialog button. Now, click on the SwingSet2 window title bar and you'll see the window rapidly gaining and loosing focus. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ Thanks, Leonid.
