Hi Sergey, the fix conceals other scenarios. Now if another fix breaks the activeWindow field logic it can be unnoticed. Do not you think it is worth to distinguish the field update on per-AppContext basis instead?
Thank you, Denis On Fri, Oct 26, 2018 at 3:33 AM Krishna Addepalli < krishna.addepa...@oracle.com> wrote: > Looks good to me. > > > On 25-Oct-2018, at 5:41 PM, Laurent Bourgès <bourges.laur...@gmail.com> > wrote: > > Hi Sergey, > > (I am not a Reviewer). > > Thanks for both the bug report and the fix, it looks good for me. > > Laurent > > Le mer. 24 oct. 2018 à 23:32, Sergey Bylokhov <sergey.bylok...@oracle.com> > a écrit : > >> Hello. >> Please review the fix for jdk 12. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211435 >> Webrev: http://cr.openjdk.java.net/~serb/8211435/webrev.00 >> >> Bug description: >> >> In the DefaultKeyboardFocusManager class we have a special field >> "activeWindow", which stores the currently active window. It is used in two >> similar cases: >> 1. If the java window gets "WINDOW_ACTIVATED" event it will try to >> send "WINDOW_DEACTIVATED" to the old active window, which is stored in the >> "activeWindow" field. >> 2. If the java component lost the focus, and the opposite component is >> not a java component, then it will try to send "WINDOW_DEACTIVATED" to the >> old active window, which is stored in the "activeWindow" field. >> >> The difference in these two cases is that in "case 1" we check the old >> active window to null[1], and the second case has no such check. The bug is >> reproduced in non-standalone mode, when we have a few Appcontexts and this >> field might be updated by different EDT in parallel. >> >> Note that the test is for OSX only, because of another bug: JDK-8204142[2] >> >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/ad9077f044be/src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java#l527 >> [2] https://bugs.openjdk.java.net/browse/JDK-8204142 > > > Laurent > > >
