On Fri, 5 Dec 2025 13:43:45 GMT, Lukasz Kostyra <[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)? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1999#issuecomment-3617792451
