282862 - Inconsistent handling of CR (0x0d) characters in pasted text

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Robin Green]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050128 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050128 Firefox/1.0

When you paste some text that includes CR/LF character sequences (0x0d followed
by 0x0a) into a textarea control in Firefox on Linux (see attached sample text
file - which MUST be opened in a text editor which leaves line breaks unchanged)
the text control behaves inconsistently.

Prior to submission, each 0x0d 0x0a pair renders as one single line break, but
in the form submission, 0x0d 0x0a is sent as two line breaks (_double_ %0D%0A)
in the "application/x-www-form-urlencoded" POST data.

Then, when you press the Back button to go back to the form, the double line
breaks appear. This is inconsistent and confusing behaviour.

Admittedly, though, it is an edge case on Linux, because the 0x0d character is
rarely seen - except e.g. in captured network communications, which was what I
was pasting in when I discovered this bug.

Reproducible: Always

Steps to Reproduce:
1. Open attached text file IN AN X11 TEXT EDITOR WHICH PRESERVES LINE BREAKS -
e.g. kate
2. Select all the text
3. In firefox, go to http://rafb.net/paste/
4. Middle-click paste into the form submission box
5. Press the Back button in Firefox
Actual Results:  
Spurious line breaks appeared in the output, and in the form when I pressed the
Back button in Firefox. At first I thought this was a bug in the pastebin, but
further investigation revealed that it was due to the presence of the "hidden"
CR characters.

Expected Results:  
Treat CR characters consistently. Either always treat them as line breaks, and
render the pasted text accordingly, or never treat them as line breaks.

This is with gtk2-2.4.14-2.fc3 on Fedora Core 3

The obvious workaround - once you realise what this bug is - is to paste into a
text editor, convert the line endings to UNIX style line endings, copy again,
and paste into Firefox. Not fast, but it works.

However, it is far from obvious to the casual user what is really going on here.

Comment 1

[Robin Green]

Attachment: Text with CR characters in it

Comment 2

[Robin Green]

Sorry, there were two errors in my original report:

- There are in fact no CR/LF sequences (0x0d 0x0a) in the file. Actually, the
sequences are all LF/CR (0x0a 0x0d), oddly enough.

- Step 4 should read "Middle-click paste into the form submission box, *and then
submit the form*".

Comment 3

[Robin Green]

Gah, _another_ two errors in my original report:

- In the form, make sure to choose "Plain Text".

- kate WON'T preserve the line endings in the paste. gedit will, however. So
don't use kate for this test.

Should I just mark this INVALID and file a new, corrected report?

Comment 4

[Boris Zbarsky [:bzbarsky]]

So the problems are:

1)  Line breaks in the DOM are always 0x0a.  Having 0x0d in the DOM is an error.
2)  When we paste, we convert from "platform" line breaks to 0x0a line breaks.
3)  "platform" line breaks means 0x0a on Unix, so the 0x0d is passed through like 
    any other binary garbage in the paste would be....

It's not clear exactly what the right behavior here is.