Closed
Bug 681229
Opened 13 years ago
Closed 13 years ago
Paste of \r\n in textarea gets converted to \n\n
Categories
(Core :: DOM: Editor, defect)
Tracking
()
RESOLVED
FIXED
mozilla9
People
(Reporter: firefox, Assigned: ehsan.akhgari)
References
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
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?
Reporter | ||
Comment 6•13 years ago
|
||
(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•13 years ago
|
||
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)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 8•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
Are you able to reproduce this with a Nighlty build? and on other platforms than GNU/Linux?
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
Reporter | ||
Comment 12•13 years ago
|
||
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•13 years ago
|
||
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.)
Reporter | ||
Comment 14•13 years ago
|
||
Sorry, I can repro this in "8.0a2 (2011-09-12)" with the same steps as above...
Comment 15•13 years ago
|
||
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?
Reporter | ||
Comment 16•13 years ago
|
||
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.
Assignee | ||
Comment 17•13 years ago
|
||
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.
Keywords: qawanted
Assignee | ||
Comment 18•13 years ago
|
||
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.
Assignee: nobody → ehsan
Blocks: 240933
Status: NEW → ASSIGNED
Keywords: regression
Version: 6 Branch → Trunk
Assignee | ||
Comment 19•13 years ago
|
||
Attachment #560233 -
Flags: review?(roc)
Attachment #560233 -
Flags: review?(roc) → review+
Assignee | ||
Comment 20•13 years ago
|
||
Flags: in-testsuite+
Target Milestone: --- → mozilla9
Assignee | ||
Comment 21•13 years ago
|
||
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.
Assignee | ||
Comment 22•13 years ago
|
||
Pushed with a fix to the test for Windows:
https://hg.mozilla.org/integration/mozilla-inbound/rev/216ad60e1e28
Comment 23•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•