Skip to content

Conversation

jonahgraham
Copy link
Contributor

@jonahgraham jonahgraham commented Sep 24, 2025

Testing the Clipboard can be difficult because there are a lot of system issues that can interfere, but of particular concern are:

  1. System clipboard managers which may take ownership of the clipboard at unexpected times.
  2. Limitations as to when processes can access clipboard, such as on Wayland where only active window can access clipboard.
  3. Different behaviour when copying within a single process than between processes.

These tests aim to resolve these issues.

For the system clipboard manager there are a lot of extra sleep calls to allow clipboard manager to complete operations before continuing tests. In addition, we run all the tests multiple times by default to ensure stability.

For the process limitations, we carefully control when the shell is created because we often cannot get focus back when shell ends up in the background. See the openAndFocusShell and openAndFocusRemote methods.

For the different behaviours, we spin up a simple Swing app in a new process (the "remote" in openAndFocusRemote above). This app can be directed, over RMI, to access the clipboard. This allows our test to place data on the clipboard and ensure that the remote app can read the data successfully.

For now this test only covers basic text (and a little of RTF). Adding Image and other transfers is part of the future work as such functionality is added in GTK4 while working on #2126

For the changes to SwtTestUtil that we required:

  1. isGTK4 moved from Test_org_eclipse_swt_widgets_Shell.java to the Utils
  2. processEvents was limited to 20 readAndDispatch calls per second due to the ordering of the targetTimestamp check. This change allows full speed readAndDispatching.
  3. getPath was refactored to allow better control of source and destination of files extracted. See extracting of class files for remote Swing app in startRemoteClipboardCommands method

Part of #2126
Split out of #2538

@jonahgraham jonahgraham added the gtk4 GTK4 issues label Sep 24, 2025
Copy link
Contributor

github-actions bot commented Sep 24, 2025

Test Results

  118 files  ±0    118 suites  ±0   11m 3s ⏱️ + 1m 13s
4 577 tests +4  4 558 ✅ +4  17 💤 ±0  2 ❌ ±0 
  298 runs  ±0    292 ✅ ±0   4 💤 ±0  2 ❌ ±0 

For more details on these failures, see this check.

Results for commit 470e3a0. ± Comparison against base commit 52c9fff.

♻️ This comment has been updated with latest results.

@jonahgraham jonahgraham self-assigned this Sep 24, 2025
@jonahgraham jonahgraham moved this to In progress in GTK4 Full Support Sep 24, 2025
@jonahgraham
Copy link
Contributor Author

My new test didn't run - I had looked at the test file next to my new test to see if I needed to manually add it to any lists. That was Test_org_eclipse_swt_custom_VerifyKeyListener which is also not running. On further examination I found 10 test classes that are not run in the suite. I assume this is an oversight and I am providing a new PR that adds all of them in.

@akurtakov
Copy link
Member

Thanks @jonahgraham . All tests are supposed to run so it's definetely an oversight.

@akurtakov akurtakov removed the gtk4 GTK4 issues label Sep 25, 2025
@akurtakov
Copy link
Member

I have removed the gtk4 label to be sure that tests work fine on gtk3 for now.

@jonahgraham jonahgraham force-pushed the clipboard-test branch 5 times, most recently from 9ab2c51 to 97b848f Compare September 25, 2025 15:15
@jonahgraham
Copy link
Contributor Author

The only failing tests are the Windows KeyEvent ones tracked in #2156.

I can see that the clipboard tests have run on all platforms, and I had to do minor fixes to get them to pass on mac + windows.

I am making a final change to only run the tests repeatedly on GTK4 since they seem stable on other platforms we don't need longer runtimes. If there is any sign of instability in these tests I will revisit. (Plus I need to rebase)

@jonahgraham jonahgraham force-pushed the clipboard-test branch 2 times, most recently from fe05092 to a00524c Compare September 25, 2025 15:21
@jonahgraham
Copy link
Contributor Author

This is ready to merge. As a few other people have had a look in here I will wait a bit for last minute comments before merging myself

Testing the Clipboard can be difficult because there are a lot of system
issues that can interfere, but of particular concern are:

1. System clipboard managers which may take ownership of the clipboard
at unexpected times.
2. Limitations as to when processes can access clipboard, such as on Wayland
where only active window can access clipboard.
3. Different behaviour when copying within a single process than between
processes.

These tests aim to resolve these issues.

For the system clipboard manager there are a lot of extra sleep calls
to allow clipboard manager to complete operations before continuing tests.
In addition, we run all the tests multiple times by default to ensure
stability.

For the process limitations, we carefully control when the shell is created
because we often cannot get focus back when shell ends up in the background.
See the openAndFocusShell and openAndFocusRemote methods.

For the different behaviours, we spin up a simple Swing app in a new
process (the "remote" in openAndFocusRemote above). This app can be
directed, over RMI, to access the clipboard. This allows our test to
place data on the clipboard and ensure that the remote app can read the
data successfully.

For now this test only covers basic text (and a little of RTF). Adding
Image and other transfers is part of the future work as such functionality
is added in GTK4 while working on #2126

For the changes to SwtTestUtil that we required:

1. isGTK4 moved from Test_org_eclipse_swt_widgets_Shell.java to the Utils
2. processEvents was limited to 20 readAndDispatch calls per second due
to the ordering of the targetTimestamp check. This change allows full speed
readAndDispatching.
3. getPath was refactored to allow better control of source and destination
of files extracted. See extracting of class files for remote Swing app
in startRemoteClipboardCommands method

Part of #2126
Split out of #2538
@jonahgraham jonahgraham merged commit 34becc0 into eclipse-platform:master Sep 25, 2025
15 of 17 checks passed
@github-project-automation github-project-automation bot moved this from In progress to Done in GTK4 Full Support Sep 25, 2025
@jonahgraham jonahgraham deleted the clipboard-test branch September 25, 2025 17:04
jonahgraham added a commit that referenced this pull request Sep 25, 2025
The test failed to get the RMI within 1 second on macOS on GitHub actions
one time, so increase the timeout here.

Fixup for #2541
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants