On Wed, 26 Mar 2025 20:20:36 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:
>
> readding flavors with changed mapping
Changes requested by lkostyra (Reviewer).
modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 207:
> 205: {
> 206: addPair(GLASS_TEXT_PLAIN, CF_UNICODETEXT);
> 207: addPair(GLASS_TEXT_PLAIN_LOCALE, CF_UNICODETEXT);
Seems like those changes made JFX unaware of text data ready to be pasted from
"outside" - running your test program and trying to paste something to a
TextBox (ex. in `HelloTextBoxClipboard`) doesn't work anymore (Paste popup menu
option is disabled, Ctrl+V does nothing, whereas both were possible to do on
master). I checked that these mime stuff changes are at fault.
My guess now would be that these mime_stuff changes have to be reverted and the
actual change should happen as we request Clipboard data - probably a condition
changing clipboard format `cf` from `CF_TEXT` and `CF_OEMTEXT` to
`CF_UNICODETEXT` right before we call `me.Load()` in `PopMemory()`. Please
check if that is in fact the case before committing though, I'm not 100% sure
if that would work.
If that works, a comment explaining why we do this clipboard format swap would
also come in handy for future generations.
-------------
PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2720659536
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2016138135
