On Tue, 1 Dec 2020 02:40:27 GMT, Tejpal Rebari <treb...@openjdk.org> wrote:
>> Well, the comment was added on Oct 15 and it got hidden on Oct28 because the
>> ac was not of github author/committer. I think the fix submitter should have
>> seen the comment lying there for 2 weeks before it got hidden.
>
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/600
