On Fri, 28 Mar 2025 15:10:46 GMT, Oliver Schmidtmer
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 tex
> 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.
On Mon, 31 Mar 2025 17:48:50 GMT, Oliver Schmidtmer
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 tex
On Mon, 31 Mar 2025 17:48:50 GMT, Oliver Schmidtmer
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 tex
On Mon, 31 Mar 2025 17:48:50 GMT, Oliver Schmidtmer
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 tex
> 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.
On Thu, 27 Mar 2025 13:14:27 GMT, Oliver Schmidtmer
wrote:
>> 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
On Thu, 27 Mar 2025 10:06:02 GMT, Lukasz Kostyra wrote:
>> Oliver Schmidtmer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> readding flavors with changed mapping
>
> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp l
On Wed, 26 Mar 2025 20:20:36 GMT, Oliver Schmidtmer
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 tex
> 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.
On Tue, 25 Mar 2025 18:39:08 GMT, Oliver Schmidtmer
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 tex
> 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.
On Tue, 25 Mar 2025 09:53:10 GMT, Lukasz Kostyra wrote:
>> As @mstr2 said, I think the data is always converted to CF_UNICODETEXT. If
>> it wasn't there should have been more visible problems, as the current code
>> always assumes wide chars.
>>
>> So I just need to know how much we should cha
On Tue, 25 Mar 2025 09:36:46 GMT, Oliver Schmidtmer
wrote:
>> Could be, but in any case, the way it's impemented right now doesn't seem to
>> be right. We should only assume 2-byte characters if what's being pulled
>> from the clipboard is actually `CF_UNICODETEXT`.
>
> As @mstr2 said, I think
On Fri, 28 Feb 2025 16:48:39 GMT, Michael Strauß wrote:
>> As the existing code was already pretty optimistic about 2 byte chars, is it
>> possible that is already handled somewhere else?
>> I'm not sure whether this is done explicitly somewhere or if CF_UNICODETEXT
>> is just tried first.
>
>
On Fri, 28 Feb 2025 16:48:39 GMT, Michael Strauß wrote:
>> As the existing code was already pretty optimistic about 2 byte chars, is it
>> possible that is already handled somewhere else?
>> I'm not sure whether this is done explicitly somewhere or if CF_UNICODETEXT
>> is just tried first.
>
>
On Thu, 27 Feb 2025 09:59:04 GMT, Oliver Schmidtmer
wrote:
>> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line
>> 406:
>>
>>> 404: cdata = 0;
>>> 405: }
>>> 406: } else if(CF_TEXT == cf || CF_UNICODETEXT == cf){
>>
>> Instead of doi
On Thu, 27 Feb 2025 03:40:47 GMT, Michael Strauß wrote:
>> Oliver Schmidtmer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> cleanup
>
> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 406:
>
>> 404:
> 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.
On Wed, 26 Feb 2025 18:28:28 GMT, Oliver Schmidtmer
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 tex
> 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.
> 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.
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Wed, 26 Feb 2025 13:22:16 GMT, Kevin Rushforth wrote:
> I can't reproduce the original bug on Windows 11.
Actually, I didn't run the test correctly earlier. I can reproduce it locally,
so I'll be able to verify the fix (once we resolve the outstanding questions).
-
PR Comment:
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Tue, 25 Feb 2025 15:24:39 GMT, Oliver Schmidtmer
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 tex
On Tue, 25 Feb 2025 15:21:22 GMT, Oliver Schmidtmer
wrote:
>> 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) {
On Tue, 25 Feb 2025 14:36:59 GMT, Kevin Rushforth wrote:
>> Oliver Schmidtmer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> check both UTF16 bytes
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java
>
> 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.
On Tue, 25 Feb 2025 14:36:38 GMT, Kevin Rushforth 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 f
On Tue, 25 Feb 2025 13:25:07 GMT, Oliver Schmidtmer
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 fi
On Tue, 25 Feb 2025 13:25:07 GMT, Oliver Schmidtmer
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 fi
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
35 matches
Mail list logo
