RFR: 8281384: Random chars on paste from Windows clipboard
Kevin Rushforth
kcr at openjdk.org
Tue Feb 25 14:47:11 UTC 2025
On Tue, 25 Feb 2025 13:25:07 GMT, Oliver Schmidtmer <oschmidtmer at 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.
I left a couple comments. As for an automated test, maybe there is something we could do with FFM, but it might be a bit of a project to figure out how to incorporate it into our test framework.
modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java line 255:
> 253: try {
> 254: // JDK-8118474 - internal Windows data null terminated
> 255: // JDK-8281384 - buffer might be larger than data and null terminator not at the end
Minor: We generally don't include the bug ID of the bug we are fixing in a comment (and I see no need here).
modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java line 258:
> 256: int nullTerm = data.length - 2;
> 257: for (int i = 0; i < data.length; i += 2) {
> 258: if (data[i] == 0) {
Since this is UTF-16, don't you need to check that both the even and odd bytes are 0?
if (data[i] == 0 && data[i+1] == 0) {
If you do this, you will want to validate that the length is even (if it isn't already ensured by `popBytes`).
-------------
PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2641322865
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1969912664
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r1969913328
More information about the openjfx-dev
mailing list