JDK-8172561 : Copying String with "\r\n" to Clipboard duplicates "\r"
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_10
  • CPU: x86
  • Submitted: 2017-01-11
  • Updated: 2020-01-31
  • Resolved: 2017-01-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u152Fixed 9Fixed
Related Reports
Duplicate :  
JDK-8087545 - Line separator is broken in the clipboard of WebView
Description
Copying text with "\r\n" to the clipboard and retrieving it outside of this very instance (eg in 2nd launch application, native application like notepad++) has duplicated the "\r" entry.

Steps to reproduce:
* Launch application
* Hit copy button
* Hit paste button
* EVERYTHING OK
* Now launch the application a second time
* Hit paste

Observation:
* the string size has been increased by 1 char
Comments
This has baked long enough in JDK 9. This is approved for backporting to 8u-dev for 8u152. If the patch applies cleanly (after adjusting for the file location difference) then no need to create a new webrev.
17-02-2017
[~tschindl] Certainly open a new bug. I *think* the intent was to handle cross platform clipboards - for example virtual box kinda environments. Would need to spend some time poking around to see how ugly that would be without this. Certainly within a single environment - say windows, it does seem odd to tweak the clipboard.
27-01-2017
Thanks David. Should we open a new bug discussing this clipboard modification at all? I still think it is not correct to modify the content pushed to the clipboard.
27-01-2017
This is certainly isolated and clean enough to consider for a backport
26-01-2017
Changeset: 1c417b74f439 Author: tschindl Date: 2017-01-26 15:05 -0500 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/1c417b74f439 8172561: Copying String with "\r\n" to Clipboard duplicates "\r" Reviewed-by: ddhill ! modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java
26-01-2017
In general I question whether javafx should modify values pushed to the native clipboard! If I copy something to the clipboard from my application i expect to find the exact same value in the systemclipboard. So if i copy a String with "\n" I expect that only "\n" shows up there. It's the job of the paste operation handler to decide what is done with the content provided. Another problem with modifying the value before pushing it to the native clipboard is that now there's a mismatch between the value found in the native clipboard and the internally cached value inside the Clipboard instance! I'm not sure if it is too late to open the discussion for 9 whether this processing should happen at all but it would be great if at least the provided patch could get integrated into 9 and even backported to 8.
13-01-2017
A small test application to show that the change does what is expected - it normalizes the line endings.
13-01-2017
The most minimal patch is to replace() the replaceAll() - I doubt from a performance point of view this makes a big difference as replace(CharSequence,CharSequence) is using Pattern.compile internally
13-01-2017
Ah ah ah the bug is in WinSystemClipboard.java in fosSerialize who does ---- ((String) data).replace("\n", "\r\n") ----
13-01-2017
I debugged the String until it gets handed over to the native part and until then the string is holding the correct line endings. I then tried to look at native code but because my c/c++ knowledge is too week I could not find the correct location \n is replaced with "\r\n". Is there a chance to get a fix for 9 and probably a backport to 8u-something?
13-01-2017
Raising the priority to P3. It seems quite wrong to be modifying the native clipboard contents in this manner, and I don't see how an application could work around it. We can certainly consider fixing this for JDK 9. I would need to take a look at whether it is a good candidate for a backport.
13-01-2017
I can reproduce this on JDK 8 and JDK 9.
12-01-2017
Improved version showing \r duplication
11-01-2017