Skip to content

Commit d6e01f9

Browse files
jonahgrahamakurtakov
authored andcommitted
[GTK] Fix HTMLTransfer loses last byte if copied data is odd length
As a follow up to Bugs 376589 & 384381 which changed the serialization deserializtion from UTF16 to UTF8, there was some remnant code that ensured input was handled in pairs of bytes that should have been moved into the UTF16 part of the new if statement. Fixes #2666
1 parent 3037102 commit d6e01f9

File tree

2 files changed

+27
-5
lines changed

2 files changed

+27
-5
lines changed

bundles/org.eclipse.swt/Eclipse SWT Drag and Drop/gtk/org/eclipse/swt/dnd/HTMLTransfer.java

Lines changed: 16 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
/*******************************************************************************
2-
* Copyright (c) 2000, 2017 IBM Corporation and others.
2+
* Copyright (c) 2000, 2025 IBM Corporation and others.
33
*
44
* This program and the accompanying materials
55
* are made available under the terms of the Eclipse Public License 2.0
@@ -90,14 +90,26 @@ public void javaToNative (Object object, TransferData transferData){
9090
@Override
9191
public Object nativeToJava(TransferData transferData){
9292
if ( !isSupportedType(transferData) || transferData.pValue == 0 ) return null;
93-
/* Ensure byteCount is a multiple of 2 bytes */
94-
int size = (transferData.format * transferData.length / 8) / 2 * 2;
93+
94+
int size = (transferData.format * transferData.length / 8);
9595
if (size <= 0) return null;
9696
char[] bom = new char[1]; // look for a Byte Order Mark
9797
if (size > 1) C.memmove (bom, transferData.pValue, 2);
9898
String string;
9999
if (bom[0] == '\ufeff' || bom[0] == '\ufffe') {
100-
// utf16
100+
// XXX Follow up to Bugs 376589 384381 this is almost
101+
// certainly wrong as it leaves the BOM as the first
102+
// character in the string. This probably should be
103+
//
104+
// byte[] bytes = new byte [size];
105+
// C.memmove (bytes, transferData.pValue, size);
106+
// string = new String(bytes, StandardCharset.UTF16);
107+
//
108+
// However I cannot find any current Linux program that
109+
// copies text/html to the clipboard in UTF16 anymore
110+
// so it is probably not a big issue
111+
/* Ensure byteCount is a multiple of 2 bytes */
112+
size = size / 2 * 2;
101113
char[] chars = new char [size/2];
102114
C.memmove (chars, transferData.pValue, size);
103115
string = new String (chars);

tests/org.eclipse.swt.tests/JUnit Tests/org/eclipse/swt/tests/junit/Test_org_eclipse_swt_dnd_HTMLTransfer.java

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -126,7 +126,17 @@ public void test_internalClone() throws Exception {
126126

127127
static Stream<Arguments> testData() {
128128
return Stream.of(//
129-
Arguments.of("hello_world", "<b>Hello, World!</b>") //
129+
Arguments.of("hello_world", "<b>Hello, World!</b>"), //
130+
/*
131+
* single_char and odd_chars are a regression test specifically for a bug that
132+
* if there was only 1 byte in the clipboard the return value of getContents was
133+
* null instead of the single character and if there was odd > 1 the last byte
134+
* would be dropped. See
135+
* https://github.com/eclipse-platform/eclipse.platform.swt/issues/2666
136+
*/
137+
Arguments.of("single_char", " "), //
138+
Arguments.of("odd_chars", "12345"), //
139+
Arguments.of("even_chars", "123456") //
130140
);
131141
}
132142

0 commit comments

Comments
 (0)