Clipboard.writeText reverses lines when pasting into PowerShell
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect)
Tracking
()
People
(Reporter: msrd0000, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: parity-chrome)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36
Steps to reproduce:
When copying text with LF line ends using navigator.clipboard.writeText, PowerShell will reverse the lines when pasting the copied text.
Example website for copying:
<!DOCTYPE html>
<html>
<head>
<title>Document</title>
</head>
<body>
<button>Click me</button>
<script>
document.querySelector("button").addEventListener("click", () => {
navigator.clipboard.writeText("abc\ndef\nghi\n")
.then(() => console.log("yay"), () => console.log("oh no"));
});
</script>
</body>
</html>
I then open a PowerShell prompt and right-click to paste the copied text.
Actual results:
PowerShell displays the following:
PS C:\Users\micha>
>> ghi
>> def
>> abc
As you can see, the lines have been reversed.
Expected results:
The lines should not have been reversed.
The problem seems to be that Firefox literally copies the LF line ends without normalizing them to CRLF on Windows. When copying the same text but with CRLF line ends, everything behaves as expected.
I reported with a bug since the issue does appear on Chrome.
This bug has first been reported here: https://github.com/PrismJS/prism/issues/3303.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Works on Ubuntu 20.04, as expected, at least with a bash terminal.
As mentioned at https://github.com/PrismJS/prism/issues/3303, it's worth noting that some receiving applications (e.g. Notepad) insert the text as expected.
|
||
Comment 3•2 years ago
|
||
Looks like Chrome just replaces LF with CRLF on Windows: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/clipboard/system_clipboard.cc;l=133;drc=cba00174ca338153b9c4f0c31ddbabaac7dd38c7. We should be able to replicate this easily.
However we also need to open a spec issue to get this behavior documented.
The spec for clipboard.writeText() currently doesn't specify a conversion of \ns to \r\ns on Windows, which Chrome seems to be performing.
That spec is currently being refined, see https://github.com/w3c/clipboard-apis/pull/158. I'll consider bringing up that topic there.
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
Description
•