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.
