Last Comment Bug 681229 - Paste of \r\n in textarea gets converted to \n\n
: Paste of \r\n in textarea gets converted to \n\n
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: x86_64 Linux
: -- normal (vote)
: mozilla9
Assigned To: :Ehsan Akhgari (busy, don't ask for review please)
:
Mentors:
Depends on:
Blocks: 240933
  Show dependency treegraph
 
Reported: 2011-08-23 05:25 PDT by Peter van der Zee
Modified: 2011-09-27 03:53 PDT (History)
10 users (show)
ehsan: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (v1) (5.03 KB, patch)
2011-09-14 13:17 PDT, :Ehsan Akhgari (busy, don't ask for review please)
roc: review+
Details | Diff | Review

Description Peter van der Zee 2011-08-23 05:25:41 PDT
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1

Steps to reproduce:

Paste characters that include Windows line ending (CRLF or \r\n) in a textarea (in Linux, Ubuntu 11.04, Firefox 6).


Actual results:

The \r\n was converted to \n\n, causing double lines to appear.


Expected results:

It should convert it to \n (or only normalize it such that it appears that way).
Comment 1 David Bruant 2011-08-23 05:45:26 PDT
On the bugzilla comment textarea:
----
var ta = document.querySelector('html body.bugzilla-mozilla-org div#bugzilla-body form#changeform div#add_comment.bz_section_additional_comments table tbody tr td textarea#comment');

ta.value = 'a\r\nb';
console.log([ta.value]); // ["a\nb"] on both WebConsole and Firebug console
----
Comment 2 Mathias Bynens 2011-08-23 05:47:31 PDT
(In reply to David Bruant from comment #1)
> On the bugzilla comment textarea:
> ----
> var ta = document.querySelector('html body.bugzilla-mozilla-org
> div#bugzilla-body form#changeform
> div#add_comment.bz_section_additional_comments table tbody tr td
> textarea#comment');
> 
> ta.value = 'a\r\nb';
> console.log([ta.value]); // ["a\nb"] on both WebConsole and Firebug console
> ----

The difference is that you’re setting the value through JavaScript.
Comment 3 Mathias Bynens 2011-08-23 05:52:46 PDT
Made a simple test case in a data URL (shortened for convenience): http://mths.be/bcz

It seems to get tokenized correctly in Firefox 6 on OS X though.
Comment 4 David Bruant 2011-08-23 05:57:20 PDT
(In reply to Mathias Bynens from comment #3)
> Made a simple test case in a data URL (shortened for convenience):
> http://mths.be/bcz
> 
> It seems to get tokenized correctly in Firefox 6 on OS X though.
PASS for me on FF6/Ubuntu/x86

(In reply to Mathias Bynens from comment #2)
> The difference is that you’re setting the value through JavaScript.
I agree, but it reduces the search area and seems to confirm the idea that it's a copy/paste-specific bug.
Comment 5 Mathias Bynens 2011-08-23 06:03:24 PDT
I tested copying the text on OS X Lion:

    echo -n $'a\r\nb' | pbcopy

…and pasting it in the textarea, then reading out the value, but it seems to get normalized to 'a\nb' just fine.

Perhaps this is an Ubuntu-specific issue?
Comment 6 Peter van der Zee 2011-08-23 06:06:30 PDT
(We're bouncing this on IRC)

My output for the same:

What I am pasting into the textarea in Firefox:

xxx@qfox:~$ xclip -o | hexdump -C
00000000  7b 0d 0a 0d 0a 7d                                 |{....}|
00000006

When I copy it back from Firefox, this is the result:

xxx@qfox:~$ xclip -o | hexdump -C
00000000  7b 0a 0a 0a 0a 7d                                 |{....}|
00000006
Comment 7 David Bruant 2011-08-23 06:23:32 PDT
I have noticed the bug too, but not all the time, it's weird.
I am wondering if "xclip -o | hexdump -C" does not influence the process.
(btw,
$> echo -n $'a\r\nb' | xclip -i
to put a string in the copy/paste buffer on Ubuntu)
Comment 8 Peter van der Zee 2011-08-23 06:27:03 PDT
Confirmed on a different machine as well. This bug also existed in Firefox 5 (Ubuntu 11.04).

Also, to actually paste the command line clipboard filler from #7 I need to do this:

$> echo -n $'a\r\nb' | xclip -i -selection clip-board
Comment 9 David Bruant 2011-08-23 06:37:04 PDT
(In reply to Peter van der Zee from comment #8)
> Also, to actually paste the command line clipboard filler from #7 I need to
> do this:
> 
> $> echo -n $'a\r\nb' | xclip -i -selection clip-board
This is for a Ctrl+V. The command i gave works with the middle-click paste buffer (or double-click if there is no middle-click).
Comment 10 Mounir Lamouri (:mounir) 2011-08-24 03:23:50 PDT
Are you able to reproduce this with a Nighlty build? and on other platforms than GNU/Linux?
Comment 11 :Ehsan Akhgari (busy, don't ask for review please) 2011-09-12 12:29:10 PDT
I can't reproduce this...
Comment 12 Peter van der Zee 2011-09-12 12:48:44 PDT
Can still reproduce this in current (newer since opening topic) Firefox (6.0.2).

html:

<!doctype html>
<html>
	<head>
		<title>crlf</title>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
	</head>
	<body>
		<textarea></textarea>
	</body>
</html>

Open terminal, make sure xclip is available, execute:

echo -n $'a\r\nb' | xclip -i -selection clip-board

Open the code above in Firefox, paste with keyboard. 

Open console. The next:

var t = document.getElementsByTagName('textarea')[0];
Array.prototype.map.call(t.value, function(c){ return c.charCodeAt(0); })

Returns:

[97, 10, 10, 98]

For me. Better yet, a simple f5 causes the page to reload with two visual returns (because it's saving the form data and parsing it again, this time properly showing what the contents actually is).

I can still repro this after some time (including Firefox updates and Ubuntu updates)...
Comment 13 Sander 2011-09-12 13:17:41 PDT
I see the same behaviour as in comment 12 on 8.0a2 on Ubuntu 10.10.
Run: echo -n $'a\r\nb' | xclip -i -selection clip-board
Paste into any textarea: only one linebreak shows.
Select all.
Copy.
Paste: Now two linebreaks show.
(Copy/select/paste can be done with either keyboard or mouse; the behaviour remains.)
Comment 14 Peter van der Zee 2011-09-12 13:24:39 PDT
Sorry, I can repro this in "8.0a2 (2011-09-12)" with the same steps as above...
Comment 15 Mounir Lamouri (:mounir) 2011-09-12 17:19:17 PDT
All browsers I've tested have the same behavior. Pidgin seems to understands the pasted sequence as 'a' followed by a break line then a space then 'b'. Which is still not the two expected break lines.

Is there any application that produce two break lines?
Comment 16 Peter van der Zee 2011-09-13 00:27:33 PDT
Please note that this is not about visual. Visually there is indeed only one line break. But when you read out textarea.value you will see \n\n rather than \r\n. That's what this bug is about.
Comment 17 :Ehsan Akhgari (busy, don't ask for review please) 2011-09-13 08:50:37 PDT
I forgot to say that I managed to reproduce this bug yesterday.  I'm trying to get my linux build working, and I will investigate what happens.  But we should just drop the carriage return characters when injecting stuff into the textarea on all platforms.  At least, that's my guess so far.
Comment 18 :Ehsan Akhgari (busy, don't ask for review please) 2011-09-14 13:15:52 PDT
OK, here's what's happening.  For pasting (and also drag-drop), we don't sanitize the platform line breaks, as we do when we set the value property.  So, later on, when obtaining the value, we get confused by the fact that there is a carriage return stored in the DOM, and we end up converting it to another line break.

This is a "regression" from bug 240933 in the sense that before that bug, we stored newlines as BR nodes, so we would magically get away with not doing proper sanitization.  That is not the case any more, which is why we see the bug now.
Comment 19 :Ehsan Akhgari (busy, don't ask for review please) 2011-09-14 13:17:07 PDT
Created attachment 560233 [details] [diff] [review]
Patch (v1)
Comment 20 :Ehsan Akhgari (busy, don't ask for review please) 2011-09-15 12:34:00 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/c0e8e3ada0ac
Comment 21 :Ehsan Akhgari (busy, don't ask for review please) 2011-09-15 14:44:50 PDT
I backed out the patch from inbound because the test fails on Windows.

https://tbpl.mozilla.org/php/getParsedLog.php?id=6415755&tree=Mozilla-Inbound&full=1

I need to investigate why.
Comment 22 :Ehsan Akhgari (busy, don't ask for review please) 2011-09-26 09:27:06 PDT
Pushed with a fix to the test for Windows:

https://hg.mozilla.org/integration/mozilla-inbound/rev/216ad60e1e28
Comment 23 Ed Morley [:emorley] 2011-09-27 03:53:51 PDT
https://hg.mozilla.org/mozilla-central/rev/216ad60e1e28

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