Skip to content

Conversation

@lukostyra
Copy link
Contributor

@lukostyra lukostyra commented Dec 5, 2025

This commit fixes the JVM crash caused by bad Clipboard data on Linux.

On Windows the Clipboard is a bit more generic in how it operates - even if the MIME type mismatches, the Clipboard will accept any object and then return it. GTK is less generic in this regard (at least our Glass implementation) so for cases like text it requires us to fetch the String contents and set those directly onto the Clipboard.

Moreover, ClipboardContent is simply an extension of HashMap which exposes put() and lets us assign whatever object we want to whatever MIME type we want. As such, if we follow the example code from the JDK issue, we would try to fetch String contents from something that is not a String, causing SIGSEGV.

Fix was done by type-checking incoming ClipboardContent data. I saw that this can also happen in other content types than text, so I guarded those as well. If types are not what we expect them to be, the attempt to update the System Clipboard is silently discarded and the crash is avoided. According to my manual testing, as long as data types are correct everything seems to work fine.

As a side-note, this also shows there is discrepancy in how Clipboard operates between platforms. We should unify that behavior, but that is a larger task which will be solved under JDK-8373090.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

  • JDK-8269630: Bad clipboard data causes JVM to crash (Bug - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1999/head:pull/1999
$ git checkout pull/1999

Update a local copy of the PR:
$ git checkout pull/1999
$ git pull https://git.openjdk.org/jfx.git pull/1999/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1999

View PR using the GUI difftool:
$ git pr show -t 1999

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1999.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Dec 5, 2025

👋 Welcome back lkostyra! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Dec 5, 2025

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk bot added the rfr Ready for review label Dec 5, 2025
@mlbridge
Copy link

mlbridge bot commented Dec 5, 2025

Webrevs

@kevinrushforth
Copy link
Member

Can you turn the test case from the bug report into an automated test?

/reviewers 2

@kevinrushforth kevinrushforth self-requested a review December 5, 2025 13:48
@openjdk
Copy link

openjdk bot commented Dec 5, 2025

@kevinrushforth
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

@lukostyra
Copy link
Contributor Author

Can you turn the test case from the bug report into an automated test?

I was not sure about this, mostly because of difference in behavior between platforms. For now I could add a test that simply sets ClipboardContent and then tries to put it on the Clipboard, but because each platform behaves differently I can't double-check if Clipboard was correctly (not) updated - Windows will return a valid object, while Linux will return null.

I can also write a proper test, make it work only on Linux assuming this is the behavior we want to follow and exclude it on other platforms, that way JDK-8373090 will have it mostly ready to go.

Which option do you prefer?

@andy-goryachev-oracle
Copy link
Contributor

andy-goryachev-oracle commented Dec 5, 2025

Questions:

  1. do we have the same issue with other text types (e.g. "text/css" or "text/javascript")?
  2. should we have an automated test developed which places mismatched data to the clipboard (it might need to be headful to operate with the real clipboard)?

Another consideration is what should happen when a single item of unacceptable data is put into the clipboard. Should it replace the existing clipboard content (possibly from another application), or should it be a no-op?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rfr Ready for review

Development

Successfully merging this pull request may close these issues.

3 participants