Carriage return replaced with newline in paste dataTransfer content outside headless mode
Categories
(Core :: DOM: Selection, defect, P3)
Tracking
()
People
(Reporter: cody.alan.owens, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36
Steps to reproduce:
Steps to reproduce:
- Open Firefox not in headless mode
- Copy text with a carriage return to the clipboard
- Paste it and inspect the actual contents of the paste data transfer string (carriage returns are often omitted or converted to other entities)
For a code reproduction, see https://codepen.io/quitedensepoint/pen/RwwagMm
There, click the 'Copy' button, then press the paste shortcut key (i.e. Ctrl + V). The output of the paste will be shown in the console.
Additionally, I am running on Windows 10. Running Firefox in headless mode, curiously, does not result in the carriage return replacement.
Actual results:
The carriage return is replaced with a newline. So, copying a\rb results in a string on getData('text/plain') of 'a\nb'
Expected results:
The carriage return is retained and not replaced with anything.
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 2•5 years ago
|
||
The priority flag is not set for this bug.
:bdahl, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•2 years ago
|
Comment 3•2 years ago
|
||
There is actually a similar bug in Chrome. In Chrome they rewrite '\n' to '\r\n' in copy action (navigator.clipboard.writeText). It is funny that there is no bug if you copy from FF and paste in Chrome O_o
I'm not sure what is the point to correct the copy/pasted text. There are scenarios in which these 'corrections' break someone's business logic. For example in our use case we process the text server side and compare the value to server version. If you 'correct' the value in copy/paste flow the server side code does not work as expected.
This bug has been open for 3 years and it is assigned P3 -> Backlog. Why is this not a bug that you want to fix? It is obviously wrong to deliberately change user input into an unexpected value.
Comment 4•2 years ago
|
||
Simple test case that reproduces the issue.
Description
•