Open Bug 1589098 Opened 5 years ago Updated 2 years ago

Carriage return replaced with newline in paste dataTransfer content outside headless mode

Categories

(Core :: DOM: Selection, defect, P3)

69 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: cody.alan.owens, Unassigned)

Details

Attachments

(2 files)

Attached file reproCode.js

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:

  1. Open Firefox not in headless mode
  2. Copy text with a carriage return to the clipboard
  3. 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.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Headless

The priority flag is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(bdahl)
Component: Headless → DOM: Events
Flags: needinfo?(bdahl)
Product: Firefox → Core
Component: DOM: Events → DOM: Selection
Priority: -- → P3
Severity: normal → S3

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.

Attached file index.html

Simple test case that reproduces the issue.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: