On Fri, 5 Dec 2025 17:19:04 GMT, Andy Goryachev <[email protected]> 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
