<AWT Dev>  Review Request: 8211435 Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source
denis.fokin at gmail.com
Fri Oct 26 13:35:56 UTC 2018
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?
On Fri, Oct 26, 2018 at 3:33 AM Krishna Addepalli <
krishna.addepalli at oracle.com> wrote:
> Looks good to me.
> On 25-Oct-2018, at 5:41 PM, Laurent Bourgès <bourges.laurent at gmail.com>
> Hi Sergey,
> (I am not a Reviewer).
> Thanks for both the bug report and the fix, it looks good for me.
> Le mer. 24 oct. 2018 à 23:32, Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
> a écrit :
>> 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, 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
>>  https://bugs.openjdk.java.net/browse/JDK-8204142
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the awt-dev