RFR: 8327401: Some jtreg tests fail on Wayland without any tracking bug

[Phil Race]

On Wed, 22 May 2024 02:52:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> These changes are intended to stabilize testing on Wayland in X11 compatibility mode.
>> 
>> <hr>
>> 
>> Many tests may fail if there is no `robot.delay()` call after `robot.waitForIdle()` (right after displaying a window).
>> <hr>
>> 
>> Some tests do not release previously pressed mouse button/key, this leads to other test failures later, but it is not a problem for X11 session.
>> I haven't checked this, but it looks like the XWayland server does not release the key/button emulated by XTEST when the client application disconnects, while the regular X11 server does.
>> 
>> <hr>
>> 
>> For some tests it is critical to call AWT code on EDT(it prevents NPE):
>> java/awt/List/KeyEventsTest/KeyEventsTest.java
>> java/awt/Paint/ListRepaint.java
>> 
>> <hr>
>> 
>> Some other explanations can be found inline in the comments for a specific test.
>> <hr>
>> 
>> Testing is green on all platforms.
>
> test/jdk/java/awt/Paint/ListRepaint.java line 40:
> 
>> 38:     static Frame frame;
>> 39: 
>> 40:     public static void main(final String[] args) throws Exception {
> 
> It is critical to call AWT code on EDT in this, otherwise it may fail with:
> 
>> java.lang.NullPointerException: Cannot read field "x" because "this.prevFocusRect" is null
> 	at java.desktop/sun.awt.X11.XListPeer$ListPainter.paintFocus(XListPeer.java:1976)
> 	at java.desktop/sun.awt.X11.XListPeer$ListPainter.paint(XListPeer.java:1830)
> 	at java.desktop/sun.awt.X11.XListPeer.repaint(XListPeer.java:389)
> 	at java.desktop/sun.awt.X11.XListPeer.repaint(XListPeer.java:364)
> 	at java.desktop/sun.awt.X11.XListPeer.repaint(XListPeer.java:360)
> 	at java.desktop/sun.awt.X11.XListPeer.select(XListPeer.java:1214)
> 	at java.desktop/java.awt.List.select(List.java:598)
> 	at ListRepaint.test(ListRepaint.java:73)
> 	at ListRepaint.main(ListRepaint.java:51)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)

I'm not sure that this should happen, (implemenation bug?) but it is outside the scope of the test updates to fix.

> test/jdk/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java line 48:
> 
>> 46:     boolean actionPerformed = false;
>> 47:     Object actionLock = new Object();
>> 48:     static final int ATTEMPTS = 10;
> 
> Each attempt sleeps for 3 seconds, so 50 attempts is way too many and exceeds the default test timeout.

OK. But I'm not seeing how this change helps the test pass.

> test/jdk/javax/swing/JButton/bug4490179.java line 57:
> 
>> 55:                 frame.getContentPane().add(button);
>> 56:                 button.addActionListener(e -> {
>> 57:                     if ((e.getModifiers() & InputEvent.BUTTON1_MASK)
> 
> This check was lost for some reason during the open sourcing of the original test, so restored.

Interesting. So since this was unconditionally setting "passed=false" how has the test been passing ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19339#discussion_r1610627456
PR Review Comment: https://git.openjdk.org/jdk/pull/19339#discussion_r1610631909
PR Review Comment: https://git.openjdk.org/jdk/pull/19339#discussion_r1610635754