RFR: 8361606 : ConsumeNextMnemonicKeyTypedTest.java fails on Windows: character typed with VK_A: a [v3]

[Anass Baya]

On Mon, 25 Aug 2025 10:16:22 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add Linux bug ID 8321303
>
> I tried running this test on Windows and the test passes without any changes. I saw in the bug that this is intermittent. How does this change to `BasicPopupMenuUI` fix the root cause of the intermittent issue?
> 
> Looks like the change is also in any instance where the action is on a non-JMenu object, which means this change might possibly affect other UI components as well other than what we expect for this intermittent failure.
> 
> Also a side-note, this test fails for me on macOS when the problemlist is for `linux-all`. And the de-problemlisting of this test may not be needed. This issue is for the windows failure it seems. There's a separate issue for the intermittent linux failure [JDK-8321303](https://bugs.openjdk.org/browse/JDK-8321303).

Hello @DamonGuy,
Thank you for your review 

> I tried running this test on Windows and the test passes without any changes. I saw in the bug that this is intermittent. How does this change to `BasicPopupMenuUI` fix the root cause of the intermittent issue?
> 
On Linux and Windows, the issue is intermittent.
By using focus and key listeners, I observed that :  

- when the issue occurs, the 'i' KeyTyped event is intercepted after the item selection is done (as a result of receiving the 'i' KeyPressed event ) and returning to the menu, So the event is treated as a normal KeyTyped rather than being recognized as part of the mnemonic sequence. As a result, it appears in the text field : 
` Test: character typed after mnemonic key press: i`

- When the issue doesn't occur, the 'i' KeyTyped event is received before returning to the menu and consumed.

So the fix approach aims to identify  Mnemonic KeyTyped event and to consume it even after the item selection is done

> Looks like the change is also in any instance where the action is on a non-JMenu object, which means this change might possibly affect other UI components as well other than what we expect for this intermittent failure.
> 

The call to the consumeProcessedKeyEvent(e) method has always been there, we just use it. The test confirms that using it does not affect keys that are typed later. In our test case, the key 'a'.

    public void processKeyEvent(Component focusedComponent, KeyEvent e) {
        // consume processed event if needed
        if (consumeProcessedKeyEvent(e)) { <--- we have taged Mnemonic KeyTyped event to be consumed here
            return;
        }
> Also a side-note, this test fails for me on macOS when the problemlist is for `linux-all`. And the de-problemlisting of this test may not be needed. This issue is for the windows failure it seems. There's a separate issue for the intermittent linux failure [JDK-8321303](https://bugs.openjdk.org/browse/JDK-8321303).

I'm not able to reproduce the issue on macOS. Could you please attach the logs so I can take a look and see if it's related to not consuming the "Next Mnemonic KeyTyped event"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26790#issuecomment-3227666839