On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer <oschmidt...@openjdk.org> wrote:
>> Windows programs may reuse a clipboard buffer that is larger than the new >> content. In this case de NUL terminator is not at the end of the buffer, but >> within it. >> The current implementation copys the whole buffer into a text field, >> including the NUL terminator and the remaining chars. >> >> The JIRA ticket contains a JNA based sample program, which prefills the >> buffer for demonstrating this issue. >> If this should be added as a unit test, I'm open for advice how to do that. > > Oliver Schmidtmer has updated the pull request incrementally with one > additional commit since the last revision: > > check both UTF16 bytes So far this change looks good, I could reproduce it with attached `ClipboardTest` program and `HelloTextArea` on my Windows 11 machine. After the fix it's no longer an issue and the contents are as expected. Tests also did not show any regressions. I do, however, have one question. I kind of wish we got correct information about how big Clipboard contents are from Windows API, and I'm kind of surprised it only gives us buffer size information and not actual content information. Are you sure we shouldn't fetch this information from Windows API somewhere instead of manually searching for a null terminator? ------------- PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2644740561
