On Thu, 10 Dec 2020 16:00:28 GMT, Tejpal Rebari <treb...@openjdk.org> wrote:
>> I have seen the comment, it is not visible in github but its there in
>> mailing-list.
>>
>> "It seems the effect is in WindowsLookAndFeel but you are fixing in Basic
>> L&F. If the cause is in Basic L&F, then it
>> would have affected other L&F also like Metal,Nimbus, doesn't it? If
>> MouseGrabber not removed is the problem, the I
>> guess MouseGrabber.uninstall() is not called. This is called in
>> BasicLookAndFeel#uninitialize() and is overridden in
>> WindowsLookAndFeel. Metal does not override this so maybe that's why the
>> issue is not seen in Metal. Probably the
>> right fix is to call this MouseGrabber.uninstall() in
>> Windows:LookAndFeel.uninitialize() same way as is done in
>> BasicLookAndFeel.uninitialize()"
>>
>> the current fix doesn't looks correct so working on finding the correct fix.
>
> In case of the first attempt to bring down the popup menu the event was
> consumed by following code of BasicPopupMenuUI
> boolean consumeEvent =
> UIManager.getBoolean("PopupMenu.consumeEventOnClose");
> // Consume the event so that normal processing stops.
> if(consumeEvent && !(src instanceof MenuElement)) {
> me.consume();
> }
> The PopupMenu.consumeEventOnClose is true for Windows, Motif, Nimbus, and GTK
> LAF and this issue is seen in all these LookAndFeels.
> For Metal LAF this variable is never set to true so it uses of
> BasicLookAndFeel which is set to FALSE
> This issue is not seen on MetalLAF.
>
> So changed PopupMenu.consumeEventOnClose to FALSE for Windows, Motif,
> Nimbus, and GTK LAF and
> it fixes the issue.
Any idea why commenting popup.setInvoker(jtb); line in the test works even
without the fix?
-------------
PR: https://git.openjdk.java.net/jdk/pull/600
