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 How about fixing this in https://github.com/openjdk/jfx/blob/7a7854c947728daab6a924baa0596ccfc2df1ebb/modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp#L383 ? It already includes special handling for `CF_DROP`, and you could add special handling for text/unicode: if (CF_TEXT == cf || CF_UNICODETEXT == cf) { ... } I also checked, it seems that Windows does not provide a way to determine the content length. For (unicode) text it indeed relyings on nul terminators. Main advantage is that it allocates the Java byte array in this function, and it could allocate it of the correct size immediately. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1724#issuecomment-2685552330
