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)

Product:
Core
Component:
DOM: Editor
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla9

People

(Reporter: firefox, Assigned: ehsan.akhgari)

References

Details

(Keywords: regression)

Attachments

(1 file)

Patch (v1)
5.03 KB, 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).
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
----
(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.
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.
(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.
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?
(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
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
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
(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).
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
I can't reproduce this...
Keywords: qawanted
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)...
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.)
Sorry, I can repro this in "8.0a2 (2011-09-12)" with the same steps as above...
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?
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.
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
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
Attached patch Patch (v1) — — Splinter Review 

        Attachment #560233 -
        Flags: review?(roc)

    
    

    
  
https://hg.mozilla.org/integration/mozilla-inbound/rev/c0e8e3ada0ac
Flags: in-testsuite+
Target Milestone: --- → mozilla9

    
    

    
  
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.

    
    

    
  
Pushed with a fix to the test for Windows:

https://hg.mozilla.org/integration/mozilla-inbound/rev/216ad60e1e28

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/216ad60e1e28
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: