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.
