Re: RFR: 8331011: [XWayland] TokenStorage fails under Security Manager [v2]
On Thu, 25 Apr 2024 17:22:48 GMT, Alexander Zvegintsev wrote: >> This fix adds missing doPrivileged calls in TokenStorage, which is used to >> help take screenshots in Wayland. > > Alexander Zvegintsev has updated the pull request incrementally with one > additional commit since the last revision: > > fix copyright years How hard is it to create a new test for this issue? - PR Comment: https://git.openjdk.org/jdk/pull/18950#issuecomment-2084434625
Re: RFR: 8280988: [XWayland] Click on title to request focus test failures [v2]
On Tue, 30 Apr 2024 02:02:30 GMT, Alexander Zvegintsev
wrote:
>> Some tests try to get the focus of a window by clicking on its title bar.
>>
>> On XWayland, however, emulating mouse clicks with XTEST currently only
>> affects the XWayland server, not the window decorations, so trying to click
>> on the window title will have no effect.
>>
>> So the solution is to click inside the window or call `toFront()` to get the
>> window focused.
>>
>> Some tests have issues with AWT/Swing calls not being on EDT, it is not the
>> goal of this change to fix them as they require way too many code changes,
>> and make this PR hard to review.
>
> Alexander Zvegintsev has updated the pull request incrementally with one
> additional commit since the last revision:
>
> review comments
test/jdk/java/awt/Focus/6981400/Test1.java line 186:
> 184: Util.clickOnComp(compToClick, robot);
> 185:
> 186: if (Platform.isOnWayland()) {
If the goal is just to move the window to the front then can we try "toFront +
click on title" on X11 and just "toFront" on Wayland?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1584163903
Re: RFR: JDK-8329692 : Add more details to FrameStateTest.java test instructions
On Mon, 29 Apr 2024 23:24:19 GMT, Harshitha Onkar wrote:
> For the following manual test, more instructions are added as to what to
> expect for "hide,iconify and show" vs "hide,iconify,show and restore" for
> clarity.
Since these lines are unchanged, can't add comments there.
1. AT L155, space after `=` is missing.
`icontst =new CreateFrame(cbIconState.getState(), cbResize.getState());`
2. In `CreateFrame` constructor, calling `pack()` is redundant as frame size is
set by `setBounds(...)` method.
3. L24 to L31 may be removed. Consolidated summary can be defined in `jtreg
summary tag`.
test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 91:
> 89:
> 90: Do the above steps for all the different Frame state combinations
> available.
> 91: For "hide,iconify and show" case, the frame is hidden then
> iconified hence Window2
Minor:
Suggestion:
For "hide, iconify and show" case, the frame is hidden then iconified
hence Window2
test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 94:
> 92: is not seen on-screen when shown as the frame is still in the
> ICONIFIED state.
> 93: Window2 is visible on-screen when it is restored to NORMAL state
> as observed with
> 94: "hide,iconify,show and restore" case.
Suggestion:
"hide, iconify, show and restore" case.
test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 112:
> 110: CheckboxGroup cbgState = new CheckboxGroup();
> 111: CheckboxGroup cbgResize = new CheckboxGroup();
> 112: Checkbox cbIconState = new Checkbox("Frame state ICONIFIED",
> cbgState, true);
Suggestion:
Checkbox cbIconState = new Checkbox("Frame State ICONIFIED", cbgState,
true);
How about capitalize each word for Checkbox text ?
test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 122:
> 120: PassFailJFrame
> 121: .builder()
> 122: .title("GetBoundsResizeTest Instructions")
Looks like title is mismatched with the test. Should it be "Frame State and
Size Test Instructions" ?
test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 326:
> 324: public void stateLog(String message) {
> 325: PassFailJFrame
> 326: .log("[Current State=%d] %s %s".formatted(getState(),
> name, message));
Suggestion:
.log("[Current State = %d] %s %s".formatted(getState(), name,
message));
test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 330:
> 328:
> 329: public void stateLog() {
> 330: PassFailJFrame.log("[Current State=" + getState() + "]");
Suggestion:
PassFailJFrame.log("[Current State = " + getState() + "]");
-
PR Review: https://git.openjdk.org/jdk/pull/19008#pullrequestreview-2030155210
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584104123
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584104632
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584098207
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584116502
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584106094
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584106363
Re: RFR: 8280988: [XWayland] Click on title to request focus test failures [v2]
On Tue, 30 Apr 2024 02:02:30 GMT, Alexander Zvegintsev wrote: >> Some tests try to get the focus of a window by clicking on its title bar. >> >> On XWayland, however, emulating mouse clicks with XTEST currently only >> affects the XWayland server, not the window decorations, so trying to click >> on the window title will have no effect. >> >> So the solution is to click inside the window or call `toFront()` to get the >> window focused. >> >> Some tests have issues with AWT/Swing calls not being on EDT, it is not the >> goal of this change to fix them as they require way too many code changes, >> and make this PR hard to review. > > Alexander Zvegintsev has updated the pull request incrementally with one > additional commit since the last revision: > > review comments test/jdk/java/awt/Focus/ModalDialogInFocusEventTest.java line 29: > 27: @bug 4531693 4636269 4681908 4688142 4691646 4721470 > 28: @summary Showing modal dialog during dispatching SequencedEvent > 29: @run main ModalDialogInFocusEventTest This test can be run standalone (`java ...`), so I prefer to keep it that way, so I didn't add the usage of `Platform.isOnWayland`. - PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1584032165
Re: RFR: 8280988: [XWayland] Click on title to request focus test failures [v2]
On Mon, 29 Apr 2024 21:08:28 GMT, Harshitha Onkar wrote:
>> Alexander Zvegintsev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review comments
>
> test/jdk/java/awt/regtesthelpers/Util.java line 674:
>
>> 672: return System.getenv("WAYLAND_DISPLAY") != null;
>> 673: }
>> 674:
>
> Is it better to have this function in `jdk/test/lib/Platform.java` since all
> the other OS-related checks are in Platform.java ?
Yes, that sounds right to me. Updated.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1584031430
Re: RFR: 8280988: [XWayland] Click on title to request focus test failures [v2]
> Some tests try to get the focus of a window by clicking on its title bar. > > On XWayland, however, emulating mouse clicks with XTEST currently only > affects the XWayland server, not the window decorations, so trying to click > on the window title will have no effect. > > So the solution is to click inside the window or call `toFront()` to get the > window focused. > > Some tests have issues with AWT/Swing calls not being on EDT, it is not the > goal of this change to fix them as they require way too many code changes, > and make this PR hard to review. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: review comments - Changes: - all: https://git.openjdk.org/jdk/pull/18995/files - new: https://git.openjdk.org/jdk/pull/18995/files/c2f63151..ef4d7716 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18995&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18995&range=00-01 Stats: 39 lines in 6 files changed: 15 ins; 12 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/18995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18995/head:pull/18995 PR: https://git.openjdk.org/jdk/pull/18995
Re: RFR: 8331011: [XWayland] TokenStorage fails under Security Manager [v2]
On Thu, 25 Apr 2024 17:22:48 GMT, Alexander Zvegintsev wrote: >> This fix adds missing doPrivileged calls in TokenStorage, which is used to >> help take screenshots in Wayland. > > Alexander Zvegintsev has updated the pull request incrementally with one > additional commit since the last revision: > > fix copyright years LGTM - Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18950#pullrequestreview-2029970599
RFR: JDK-8329692 : Add more details to FrameStateTest.java test instructions
For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity. - Commit messages: - minor update - added instructions for clarity Changes: https://git.openjdk.org/jdk/pull/19008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329692 Stats: 15 lines in 1 file changed: 4 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/19008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19008/head:pull/19008 PR: https://git.openjdk.org/jdk/pull/19008
Re: RFR: 8280988: [XWayland] Click on title to request focus test failures
On Mon, 29 Apr 2024 10:44:37 GMT, Alexander Zvegintsev
wrote:
> Some tests try to get the focus of a window by clicking on its title bar.
>
> On XWayland, however, emulating mouse clicks with XTEST currently only
> affects the XWayland server, not the window decorations, so trying to click
> on the window title will have no effect.
>
> So the solution is to click inside the window or call `toFront()` to get the
> window focused.
>
> Some tests have issues with AWT/Swing calls not being on EDT, it is not the
> goal of this change to fix them as they require way too many code changes,
> and make this PR hard to review.
test/jdk/java/awt/regtesthelpers/Util.java line 674:
> 672: return System.getenv("WAYLAND_DISPLAY") != null;
> 673: }
> 674:
Is it better to have this function in `jdk/test/lib/Platform.java` since all
the other OS-related checks are in Platform.java ?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1583774219
Re: RFR: 8328999: Update GIFlib to 5.2.2
On Fri, 26 Apr 2024 22:02:38 GMT, Phil Race wrote: >> Updating giflib, clientlibs tests are green on all platforms > > src/java.desktop/share/native/libsplashscreen/giflib/gif_hash.h line 40: > >> 38: #include >> 39: #endif >> 40: /** End JDK modifications to support building on Windows **/ > > Do we still need this ? The GIFLIB version 5.2.2 adds the `ifndef` wrap, so it looks like our comment can be removed - PR Review Comment: https://git.openjdk.org/jdk/pull/18985#discussion_r1583770021
Re: RFR: 8280988: [XWayland] Click on title to request focus test failures
On Mon, 29 Apr 2024 10:44:37 GMT, Alexander Zvegintsev wrote: > Some tests try to get the focus of a window by clicking on its title bar. > > On XWayland, however, emulating mouse clicks with XTEST currently only > affects the XWayland server, not the window decorations, so trying to click > on the window title will have no effect. > > So the solution is to click inside the window or call `toFront()` to get the > window focused. > > Some tests have issues with AWT/Swing calls not being on EDT, it is not the > goal of this change to fix them as they require way too many code changes, > and make this PR hard to review. Tested on Ubuntu 23.04. Changes look good. test/jdk/java/awt/Focus/ModalDialogInFocusEventTest.java line 29: > 27: @summary Showing modal dialog during dispatching SequencedEvent > 28: @key headful > 29: @run main ModalDialogInFocusEventTest Minor: Better to have the `@key` tag after `@test`. - Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18995#pullrequestreview-2029591268 PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1583728864
Re: RFR: 8331142: Add test for number of loader threads in BasicDirectoryModel [v2]
> This PR provides a regression test for > [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in > BasicDirectoryModel.validateFileCache_ reviewed in #18111. > > The test is inspired and based on `ConcurrentModification` that I wrote for > [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / > [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670). > > **How the test works** > > The test creates a temporary directory in the current directory and creates a > number of files in it. (The number of files is controlled by > `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the > temporary directory. > > The test starts several scanner threads, the number is controlled by > `NUMBER_OF_THREADS`, which repeatedly call > `fileChooser.rescanCurrentDirectory()`. This results in calling > `BasicDirectoryModel.validateFileCache` which starts a background thread — > "Basic L&F File Loading Thread" — to enumerate the files. > > The test runner thread and scanner threads are synchronised with > `CyclicBarrier`, this ensures all the scanner threads start at the same time. > After a short delay, the runner thread takes a snapshot of live threads. > After a longer delay, the operation is repeated. See the `getThreadSnapshot` > method. (The number of snapshots is controlled by `SNAPSHOTS` constant.) > > The number of File Loading Threads in each snapshot is counted. There should > be no more than two threads. It is possible that thread two such threads > after JDK-8325179 is fixed: the existing thread is interrupted but hasn't > exited yet, and a new thread is already created. > > The test fails consistently without the fix for JDK-8325179. On Windows, the > output looks like this: > > > Number of snapshots: 20 > Number of snapshots where number of loader threads: > = 1: 0 > = 2: 0 > > 2: 20 > java.lang.RuntimeException: Detected 20 snapshots with several loading threads > at LoaderThreadCount.runTest(LoaderThreadCount.java:132) > at LoaderThreadCount.wrapper(LoaderThreadCount.java:72) > at java.base/java.lang.Thread.run(Thread.java:1583) > > > On Linux and macOS, there's more variation, for example I got the following > output on one of Linux systems: > > > Number of snapshots: 15 > Number of snapshots where number of loader threads: > = 1: 7 > = 2: 2 > > 2: 6 > > > The test passes on the builds where JDK-8325179 is present. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Suppress throwing exceptions while deleting files - Changes: - all: https://git.openjdk.org/jdk/pull/18957/files - new: https://git.openjdk.org/jdk/pull/18957/files/49723a37..16136976 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18957&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18957&range=00-01 Stats: 15 lines in 1 file changed: 13 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18957/head:pull/18957 PR: https://git.openjdk.org/jdk/pull/18957
Re: RFR: 8331142: Add test for number of loader threads in BasicDirectoryModel
On Mon, 29 Apr 2024 14:45:43 GMT, Tejesh R wrote: > > Is it necessary to create dummy files here in this test? Can't we just > > create JFileChooser without creating dummy files and proceed with loader > > test? Because I tested without using dummy files and getting exception > > without JDK-8325179 fix. > > Yes, it is necessary to create the dummy files. The background threads need > to run for a while; if there are no files, the threads may complete before > the snapshot is created. > > Windows is usually less affected because all scanning on Windows is > serialized via the COM thread. Linux and macOS aren't stable enough without > the files. Even with the files, in one of the runs on Linux, there were only > 4 snapshots which contained the File Loader threads. That is 4 out of 20 > snapshots taken. Without the files and with less files, the test could pass > where it should fail. You are right, failure is unpredictable in linux unlike in Windows. Test looks good to me. - PR Comment: https://git.openjdk.org/jdk/pull/18957#issuecomment-2083225265
Re: RFR: 8331142: Add test for number of loader threads in BasicDirectoryModel
On Thu, 25 Apr 2024 16:37:39 GMT, Alexey Ivanov wrote: > This PR provides a regression test for > [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in > BasicDirectoryModel.validateFileCache_ reviewed in #18111. > > The test is inspired and based on `ConcurrentModification` that I wrote for > [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / > [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670). > > **How the test works** > > The test creates a temporary directory in the current directory and creates a > number of files in it. (The number of files is controlled by > `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the > temporary directory. > > The test starts several scanner threads, the number is controlled by > `NUMBER_OF_THREADS`, which repeatedly call > `fileChooser.rescanCurrentDirectory()`. This results in calling > `BasicDirectoryModel.validateFileCache` which starts a background thread — > "Basic L&F File Loading Thread" — to enumerate the files. > > The test runner thread and scanner threads are synchronised with > `CyclicBarrier`, this ensures all the scanner threads start at the same time. > After a short delay, the runner thread takes a snapshot of live threads. > After a longer delay, the operation is repeated. See the `getThreadSnapshot` > method. (The number of snapshots is controlled by `SNAPSHOTS` constant.) > > The number of File Loading Threads in each snapshot is counted. There should > be no more than two threads. It is possible that thread two such threads > after JDK-8325179 is fixed: the existing thread is interrupted but hasn't > exited yet, and a new thread is already created. > > The test fails consistently without the fix for JDK-8325179. On Windows, the > output looks like this: > > > Number of snapshots: 20 > Number of snapshots where number of loader threads: > = 1: 0 > = 2: 0 > > 2: 20 > java.lang.RuntimeException: Detected 20 snapshots with several loading threads > at LoaderThreadCount.runTest(LoaderThreadCount.java:132) > at LoaderThreadCount.wrapper(LoaderThreadCount.java:72) > at java.base/java.lang.Thread.run(Thread.java:1583) > > > On Linux and macOS, there's more variation, for example I got the following > output on one of Linux systems: > > > Number of snapshots: 15 > Number of snapshots where number of loader threads: > = 1: 7 > = 2: 2 > > 2: 6 > > > The test passes on the builds where JDK-8325179 is present. Marked as reviewed by tr (Committer). - PR Review: https://git.openjdk.org/jdk/pull/18957#pullrequestreview-2029067659
Integrated: JDK-8329004 : Update Libpng to 1.6.43
On Thu, 25 Apr 2024 22:28:06 GMT, Harshitha Onkar wrote: > Libpng updated from 1.6.40 to 1.6.43 This pull request has now been integrated. Changeset: 4e422943 Author:Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/4e4229438ad2e8ac59ac675465e4d3d4e13bf156 Stats: 610 lines in 18 files changed: 258 ins; 120 del; 232 mod 8329004: Update Libpng to 1.6.43 Reviewed-by: prr, dnguyen - PR: https://git.openjdk.org/jdk/pull/18964
Re: RFR: 8280988: [XWayland] Click on title to request focus test failures
On Mon, 29 Apr 2024 10:44:37 GMT, Alexander Zvegintsev wrote: > Some tests try to get the focus of a window by clicking on its title bar. > > On XWayland, however, emulating mouse clicks with XTEST currently only > affects the XWayland server, not the window decorations, so trying to click > on the window title will have no effect. > > So the solution is to click inside the window or call `toFront()` to get the > window focused. > > Some tests have problems with AWT/Swing calls not being on EDT, it is not the > goal of this change to fix them as they require way too many code changes, > and make this PR hard to review. @honkar-jdk @prrace please review - PR Comment: https://git.openjdk.org/jdk/pull/18995#issuecomment-2083087917
Re: RFR: 8331142: Add test for number of loader threads in BasicDirectoryModel
On Mon, 29 Apr 2024 13:22:00 GMT, Alexey Ivanov wrote: > > Is it necessary to create dummy files here in this test? Can't we just > > create JFileChooser without creating dummy files and proceed with loader > > test? Because I tested without using dummy files and getting exception > > without JDK-8325179 fix. > > Yes, it is necessary to create the dummy files. The background threads need > to run for a while; if there are no files, the threads may complete before > the snapshot is created. > > Windows is usually less affected because all scanning on Windows is > serialized via the COM thread. Linux and macOS aren't stable enough without > the files. Even with the files, in one of the runs on Linux, there were only > 4 snapshots which contained the File Loader threads. That is 4 out of 20 > snapshots taken. Without the files and with less files, the test could pass > where it should fail. Yeah, my observation was w.r.t windows. Will have to test in Linux then. - PR Comment: https://git.openjdk.org/jdk/pull/18957#issuecomment-2082940642
Re: RFR: 8331142: Add test for number of loader threads in BasicDirectoryModel
On Mon, 29 Apr 2024 10:42:26 GMT, Tejesh R wrote: > Is it necessary to create dummy files here in this test? Can't we just create > JFileChooser without creating dummy files and proceed with loader test? > Because I tested without using dummy files and getting exception without > JDK-8325179 fix. Yes, it is necessary to create the dummy files. The background threads need to run for a while; if there are no files, the threads may complete before the snapshot is created. Windows is usually less affected because all scanning on Windows is serialized via the COM thread. Linux and macOS aren't stable enough without the files. Even with the files, in one of the runs on Linux, there were only 4 snapshots which contained the File Loader threads. That is 4 out of 20 snapshots taken. Without the files and with less files, the test could pass where it should fail. - PR Comment: https://git.openjdk.org/jdk/pull/18957#issuecomment-2082732906
Re: RFR: 8305072: Win32ShellFolder2.compareTo is inconsistent [v2]
On Mon, 29 Apr 2024 12:44:14 GMT, Joel Uckelman wrote: > Will this be backported to Java 21 and 22? It would be very helpful if it > could be. It is already backported to 22. I'm working on backporting it to all supported Oracle releases of Java. It is up to the OpenJDK community to backport the changeset into OpenJDK-based releases. - PR Comment: https://git.openjdk.org/jdk/pull/18126#issuecomment-2082703443
Re: RFR: 8305072: Win32ShellFolder2.compareTo is inconsistent [v2]
On Tue, 5 Mar 2024 17:40:01 GMT, Alexey Ivanov wrote: >> The implementation of `Win32ShellFolder2.compareTo` is inconsistent: there >> are cases where >> `a < b & b < c but a == c` >> which *violates its general contract*. >> >> In particular, it happens for the personal folder (*Documents*) if it is >> listed *twice*: as a special and as a regular folder. >> >> The evaluation performed by the submitter of the bug provided enough details >> to create a test, reproduce the problem and finally resolve it. >> >> Without the fix, the regression test always fails: >> >> a < b & b < c but a >= c >> where >> a = C:\Users\Documents(true) >> b = C:\Users(false) >> c = C:\Users\Documents(false) >> >> as well as for the reverse case: `a > b & b > c`. >> >> How it is possible to have the same folder in a list of files twice remains >> unknown. I believe it is another bug in JDK, however, no one has been able >> to reproduce it so far. > > Alexey Ivanov has updated the pull request incrementally with one additional > commit since the last revision: > > Handle fakePersonal on Windows 10 > > The desktop folder on Windows 10 does not include > the Personal (Documents) folder. Will this be backported to Java 21 and 22? It would be very helpful if it could be. - PR Comment: https://git.openjdk.org/jdk/pull/18126#issuecomment-2082632924
Re: RFR: 8280988: [XWayland] Click on title to request focus test failures
On Mon, 29 Apr 2024 10:44:37 GMT, Alexander Zvegintsev wrote: > Some tests try to get the focus of a window by clicking on its title bar. > > On XWayland, however, emulating mouse clicks with XTEST currently only > affects the XWayland server, not the window decorations, so trying to click > on the window title will have no effect. > > So the solution is to click inside the window or call `toFront()` to get the > window focused. > > Some tests have problems with AWT/Swing calls not being on EDT, it is not the > goal of this change to fix them as they require way too many code changes, > and make this PR hard to review. test/jdk/java/awt/Focus/ModalDialogInFocusEventTest.java line 25: > 23: > 24: /* > 25: @test For some reason, this test was not enabled when it was open sourced, so enable it. Testing is green on all platforms. - PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1582855462
RFR: 8280988: [XWayland] Click on title to request focus test failures
Some tests try to get the focus of a window by clicking on its title bar. On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect. So the solution is to click inside the window or call `toFront()` to get the window focused. Some tests have problems with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review. - Commit messages: - initial Changes: https://git.openjdk.org/jdk/pull/18995/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18995&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8280988 Stats: 239 lines in 5 files changed: 125 ins; 45 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/18995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18995/head:pull/18995 PR: https://git.openjdk.org/jdk/pull/18995
Re: RFR: 8331142: Add test for number of loader threads in BasicDirectoryModel
On Thu, 25 Apr 2024 16:37:39 GMT, Alexey Ivanov wrote: > This PR provides a regression test for > [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in > BasicDirectoryModel.validateFileCache_ reviewed in #18111. > > The test is inspired and based on `ConcurrentModification` that I wrote for > [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / > [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670). > > **How the test works** > > The test creates a temporary directory in the current directory and creates a > number of files in it. (The number of files is controlled by > `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the > temporary directory. > > The test starts several scanner threads, the number is controlled by > `NUMBER_OF_THREADS`, which repeatedly call > `fileChooser.rescanCurrentDirectory()`. This results in calling > `BasicDirectoryModel.validateFileCache` which starts a background thread — > "Basic L&F File Loading Thread" — to enumerate the files. > > The test runner thread and scanner threads are synchronised with > `CyclicBarrier`, this ensures all the scanner threads start at the same time. > After a short delay, the runner thread takes a snapshot of live threads. > After a longer delay, the operation is repeated. See the `getThreadSnapshot` > method. (The number of snapshots is controlled by `SNAPSHOTS` constant.) > > The number of File Loading Threads in each snapshot is counted. There should > be no more than two threads. It is possible that thread two such threads > after JDK-8325179 is fixed: the existing thread is interrupted but hasn't > exited yet, and a new thread is already created. > > The test fails consistently without the fix for JDK-8325179. On Windows, the > output looks like this: > > > Number of snapshots: 20 > Number of snapshots where number of loader threads: > = 1: 0 > = 2: 0 > > 2: 20 > java.lang.RuntimeException: Detected 20 snapshots with several loading threads > at LoaderThreadCount.runTest(LoaderThreadCount.java:132) > at LoaderThreadCount.wrapper(LoaderThreadCount.java:72) > at java.base/java.lang.Thread.run(Thread.java:1583) > > > On Linux and macOS, there's more variation, for example I got the following > output on one of Linux systems: > > > Number of snapshots: 15 > Number of snapshots where number of loader threads: > = 1: 7 > = 2: 2 > > 2: 6 > > > The test passes on the builds where JDK-8325179 is present. Is it necessary to create dummy files here in this test? Can't we just create JFileChooser without creating dummy files and proceed with loader test? Because I tested without using dummy files and getting exception without JDK-8325179 fix. - PR Review: https://git.openjdk.org/jdk/pull/18957#pullrequestreview-2028095745
RFR: 8155030: The Menu Mnemonics are always displayed for GTK LAF
In GTK LAF, the menu mnemonics are always displayed which is different from the native behavior. In native application **(tested with gedit**), the menu mnemonics toggle on press of `ALT` key. Menu mnemonics are hidden initially and then toggles between show/hide on `ALT` press. Proposed fix is to handle the `ALT` key press for GTK LAF and mimic the native behavior. Fix is similar to the `ALT` key processing in Windows LAF. Automated test case is added to verify the fix and tested in Ubuntu and Oracle linux. CI testing was green and link attached in JBS. - Commit messages: - Mnemonic toggle fix Changes: https://git.openjdk.org/jdk/pull/18992/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18992&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8155030 Stats: 241 lines in 4 files changed: 237 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18992/head:pull/18992 PR: https://git.openjdk.org/jdk/pull/18992
