RFR: 8269630: Bad clipboard data causes JVM to crash

[Lukasz Kostyra]

On Fri, 5 Dec 2025 17:19:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> 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](https://bugs.openjdk.org/browse/JDK-8373090).
>
> 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?

@andy-goryachev-oracle 

> do we have the same issue with other text types (e.g. "text/css" or "text/javascript")?

Those types are not mentioned in `DataFormat.java`. `ClipboardContent` can only take `DataFormat` entries as keys. I would assume those are unsupported.

> 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)?

Absolutely! Although, as I mentioned in the previous comment to @kevinrushforth we don't really have a way to make this test platform independent yet due to different platforms behaving differently in this scenario.

I can make it Linux-only for now based on this change, and we can "free it" to other platforms with [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090) but then the question is - what should be the expected behavior? With this change on Linux we assume silently that nothing happens, but maybe we should expect an Exception? I think it doesn't make much sense to write a whole test if we plan to make some changes to the API and have to inevitably adjust or even rewrite it - it would make more sense to establish those tests with [JDK-8373090](https://bugs.openjdk.org/browse/JDK-8373090).

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

PR Comment: https://git.openjdk.org/jfx/pull/1999#issuecomment-3627155212