Community
Participate
Working Groups
Please launch the attached sample on Windows and Linux. On Windows you can see the "world", on Linux you can't.
Created attachment 271881 [details] Sample code
Created attachment 271882 [details] Screenshot on Windows 10
Created attachment 271883 [details] Screenshot on Ubuntu 16.04
I can reproduce the issue on 4.8M4, GTK3.22, Fedora 27. Happens on GTK2.24 as well.
The eclipse console view will handle \u0000 in the same way, so doing a System.out.println will only show hello in eclipse console but helloworld in a consol (at least my console in Linux mint). Also variables view and tooltip when debugging will display hello rather then helloworld.
New Gerrit change created: https://git.eclipse.org/r/113593
I have submitted a fix that works for StyledText, the consol and for the variable view details pane. But it will still cut the string on the variable tree itself since TreeItems are specifically set to be null terminated.
(In reply to Björn Arnelid from comment #7) > I have submitted a fix that works for StyledText, the consol and for the > variable view details pane. > > But it will still cut the string on the variable tree itself since TreeItems > are specifically set to be null terminated. I'll take a look at your patch today.
New Gerrit change created: https://git.eclipse.org/r/114402
Gerrit change https://git.eclipse.org/r/114402 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=aa9e2b45dfa29b90beca2ed2b31a641b04d8e925
(In reply to Eclipse Genie from comment #10) > Gerrit change https://git.eclipse.org/r/114402 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=aa9e2b45dfa29b90beca2ed2b31a641b04d8e925 Bug snippet merged.
When reviewing the patch for this bug, Bjorn and I ran into some issues which merit some discussion. Displaying the text after the null terminator doesn't require much work. However we also need to fix copying + pasting, as displaying the text and then copying it only copies what comes before the null character. This means that the user would see "helloworld", but copying that text only copies "hello". AFAIK, GTK clipboards are null terminated by default, so to fix this we'd have to strip out the null characters before sending them to the keyboard. I don't think this is a good approach though. It could lead to cases like malicious text being inserted after the null character which then end up in the clipboard. And after thinking about it, I'm not sure it's even reasonable to expect text after a null terminator to be displayed. What do you think? Thomas, when running the snippet on Windows, what text is copied to the clipboard?
On Windows 10 just "hello" is pasted if "hello\u0000world" had been copied.
(In reply to Thomas Singer from comment #13) > On Windows 10 just "hello" is pasted if "hello\u0000world" had been copied. I'm not sure if we should enable this behaviour on GTK, or if we should patch Windows to not display text after the null character. Or do nothing and add some info to the StyledText.setText() Javadocs about null characters. IMO the user should expect that copying the text displayed in the StyledText would mean that all the text is copied, not some portion of it. I would prefer to leave GTK as it is and modify the Javadocs to reflect platform dependent behaviour when it comes to null terminated strings. Does anyone else have any thoughts?
(In reply to Eric Williams from comment #14) > I'm not sure if we should enable this behaviour on GTK, or if we should > patch Windows to not display text after the null character. Or do nothing > and add some info to the StyledText.setText() Javadocs about null characters. > > IMO the user should expect that copying the text displayed in the StyledText > would mean that all the text is copied, not some portion of it. I would > prefer to leave GTK as it is and modify the Javadocs to reflect platform > dependent behaviour when it comes to null terminated strings. > > Does anyone else have any thoughts? I dont think i agree, StyledText is specifically trying to not be null terminated while displaying text and null terminated when copying text. It doesnt really makes sense that we are not honoring this in our converter? If this is the behavior we want, should we not implement this fix and set StyledText to be null terminated, or make all strings null terminated in the linux Converter function to make it more clear that this is what is happening?
(In reply to Björn Arnelid from comment #15) > > I dont think i agree, StyledText is specifically trying to not be null > terminated while displaying text and null terminated when copying text. Is this the intention of StyledText? AFAICT the difference seems to be platform dependent, I don't see this in the documentation.
(In reply to Eric Williams from comment #16) > Is this the intention of StyledText? AFAICT the difference seems to be > platform dependent, I don't see this in the documentation. It is not documented as far as i can see, but since the call to Converter is hard coded to false it seems to be intentional. There are a lot of other widgets using Converter that are supposed to be null terminated where this works as intended, Labels and TreeItems for instance.
Reading the method description again i(In reply to Eric Williams from comment #14) > (In reply to Thomas Singer from comment #13) > > On Windows 10 just "hello" is pasted if "hello\u0000world" had been copied. > > I'm not sure if we should enable this behaviour on GTK, or if we should > patch Windows to not display text after the null character. Or do nothing > and add some info to the StyledText.setText() Javadocs about null characters. > > IMO the user should expect that copying the text displayed in the StyledText > would mean that all the text is copied, not some portion of it. I would > prefer to leave GTK as it is and modify the Javadocs to reflect platform > dependent behaviour when it comes to null terminated strings. > > Does anyone else have any thoughts? Actually after reading the method description again and digging around some more i do agree with you.
Alternative suggestion: add a static String field with a setter. If it is empty, the \u0000 will not be escaped, otherwise the specified string will be escaped. That way any application developer can decide on its own how to handle this case.
*** Bug 412659 has been marked as a duplicate of this bug. ***
(In reply to Thomas Singer from comment #19) > Alternative suggestion: add a static String field with a setter. If it is > empty, the \u0000 will not be escaped, otherwise the specified string will > be escaped. That way any application developer can decide on its own how to > handle this case. Thomas if you are willing to provide a patch I will be happy to review it.
Created attachment 281725 [details] debug variables screenshot Is this the same root cause for the Variables view not displaying characters after \0 containing strings? From the original example from Thomas, step into setText and you can see the variables view as attached shows the same error.
(In reply to Jonah Graham from comment #22) > Created attachment 281725 [details] > debug variables screenshot > > Is this the same root cause for the Variables view not displaying characters > after \0 containing strings? > > From the original example from Thomas, step into setText and you can see the > variables view as attached shows the same error. Yes, see Comment #5.
Any updates for this issue? How about a preference for displaying text after the null terminator and let the user pick?
