New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 20 users
Status: Verified
Email to this user bounced
Closed: Feb 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 0
Type: Bug-Regression

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Pasting text into a single-line text field shouldn't keep literal newlines
Reported by, Dec 6 2011 Back to list
Chrome Version       : 17.0.962.0
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
  Firefox 4.x: OK
     IE 7/8/9: OK

What steps will reproduce the problem?
1.  Copy a cell of data from Excel.
2.  Go to a webpage with an input field.
3.  Paste the contents of the data from Excel.
4.  The data does not show in the input field as long as that field as the focus.  Once you click out of the input field, the data shows.  But, then it is not aligned correctly.  (Attaching screen shot showing the misalignment).

What is the expected result?
Once I paste the data it should show up in the input field.

What happens instead?
The data does not show until after I click out of the input field.

Please provide any additional information below. Attach a screenshot if

UserAgentString: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.962.0 Safari/535.11

This is happening with the current dev release (17.0.942.0 dev-m) and with the Canary release.
2.5 KB View Download
Comment 1 by, Dec 6 2011
Labels: -Area-Undefined Area-WebKit WebKit-Editing WebKit-Forms
Comment 2 by, Jan 16 2012
I have this problem as well. Additional information is that this is not specifically Excel related.

If the text in the copy/paste buffer is terminated with a CR/LF, the text field accepts those characters when normally it should not.

This can also be reproduced with notepad by just selecting 2 lines of text, copy, go to an INPUT TYPE=TEXT field in chrome and paste.

The reason you can't see the data is because the CR/LF scroll the contents of the text field upward like a very tiny TEXTAREA. This should not happen and does not happen in any other browser.

Pressing BACKSPACE a couple times after pasting will remove the spurious New Line character(s).

Comment 3 by, Jan 16 2012
Labels: -OS-Windows OS-All
Status: Available
Is this a regression? I feel like it used to convert newlines into spaces.
Comment 4 by, Jan 16 2012
Labels: -Type-Bug Type-Regression
I reproduced this issue on Chrome 18 Windows and Mac, but not on Chrome 16 Mac.
This might be related to  Issue 109066 .

Comment 5 by, Jan 16 2012
Summary: Pasting text into a single-line text field shouldn't keep literal newlines (was: NULL)
110183 may also be related, but I don't have Excel available to test atm.
Comment 6 by, Jan 16 2012
As the comment #2 says, we can reproduce this by copying from notepad.exe.

How to reproduce on Mac:
1. Open Emacs
2. Switch to *scratch* buffer
5. Type the following:
6. C-space at the 'a'
7. M-w at the beginning of the next line of "ghi"
8. ⌘-v on an <input> field

We replace newline characters with spaces at
I'm don't know why this problem happens.

Comment 7 by, Jan 16 2012
I would say is a duplicate.

IMO, and to work like the other popular browsers, the final \r\n needs to be truncated, not converted to a space.

FireFox: "A\nB\nC\n" goes into text field as "A B C"
Chrome: "A\nB\nC\n" appears to go into text field as "A B C \n"

The funny thing is, according to the javascript console in Chrome, the text field where for "A B C \n" is stored .val() IS "A B C" and also .val().length is 5, which both are correct.

Another interesting thing is, once you submit the form, even though the javascript console does not show these characters, what is submitted is "A B C%2520"

Comment 8 by, Jan 16 2012
Sorry, my previous comment was based on jQuery, and it does produce different results than the native:
document.getElementById( "text_id" ).value

"A\nB\nC\n" is returned as "A B C " with a length of 6 and IMO it should return "A B C" length 5. Display is still wonky and what is sent via submitted form is odd (%2520 == %20 == " ")

Anyway, I'll stop spamming now, but I paste a lot from excel so this is a little speed bump every time I do.

Comment 9 by, Jan 17 2012
 Issue 110183  has been merged into this issue.
As I said in the duplicated and closed  this worked correctly in other browsers: Firefox, IE, Safari, both in Mac and PC, and using both MS Excel and Calc

When a cell from the spreadsheet is copied and pasted on a text field in Chrome, it adds up a blank space/new line

7.9 KB View Download
Comment 11 Deleted
Comment 12 by, Feb 13 2012
 Issue 113623  has been merged into this issue.
Comment 13 by, Feb 13 2012
Labels: -Pri-2 Pri-1
Status: Assigned
I confirmed this regression was caused by:  div { display: none; } makes pasting into text fields impossible

Comment 14 by, Feb 14 2012
 Issue 113988  has been merged into this issue.
Comment 15 by, Feb 14 2012
I'm going to look into this issue later today.
Comment 16 by, Feb 19 2012
Labels: -Pri-1 Pri-0 Mstone-17
This regression is a quite serious one and the fix should be merged into m-17. It appears that some aspect of this regression is only reproducible on Windows. I'll take a deeper look into this issue now that I'm mostly done fixing security bugs.
Comment 17 by, Feb 23 2012
 Issue 115096  has been merged into this issue.
Comment 18 by, Feb 23 2012
Labels: WebKit-ID-79305
Project Member Comment 19 by, Feb 23 2012
Labels: -WebKit-ID-79305 WebKit-ID-79305-NEW
Comment 20 by, Feb 23 2012
I've posted a WebKit patch.
Comment 21 by, Feb 23 2012
The webkit bug report says:

Expected result:
See "abc def " in the text field

I believe it should be "abc def" (with no trailing space). This is how it works in at least FireFox. The trailing space is unexpected and could cause problems for example when copy/pasting a username/password for example and the trailing space in a password field would not be obvious.
Project Member Comment 22 by, Feb 23 2012
Labels: -WebKit-ID-79305-NEW WebKit-ID-79305-RESOLVED
Comment 23 by, Feb 23 2012
Should be fixed in Should be fixed in
Comment 24 by, Feb 23 2012
> I believe it should be "abc def" (with no trailing space)

I don't think that's the way WebKit worked prior to this regression so I won't be making that change. If you believe this should be new behavior, please file a separate WebKit bug on
Comment 25 by, Feb 24 2012
Sigh... I checked an older version of Chrome and you're right, the trailing space is there and somehow I never noticed it. (So maybe not such a big deal...)

Thanks for addressing the primary problem!
Comment 26 by, Feb 27 2012
 Issue 115642  has been merged into this issue.
Comment 27 by, Feb 27 2012
 Issue 115778  has been merged into this issue.
Comment 28 by, Feb 27 2012
Labels: Merge-Requested
Status: Verified
Verified this was fixed with 19.0.1053.0 canary.

Comment 29 by, Feb 27 2012
Labels: ReleaseBlock-Stable
Comment 30 by, Feb 27 2012
Labels: -Merge-Requested -ReleaseBlock-Stable Merge-Approved
Not a blocker, but ok to merge.
Comment 31 by, Feb 27 2012
Merged into 963 branch in
Comment 32 by, Feb 29 2012
@rniwa, Would you merge the fix to 1025 branch too?

Comment 33 by, Feb 29 2012
Sure.  Done in
Labels: -Merge-Approved Merge-Merged
Comment 35 by, Mar 12 2012
For completeness, I finally created the "trailing space" issue in the webkit bugzilla and just noting it here for informational purposes.
Comment 36 by, Mar 13 2012
 Issue 117506  has been merged into this issue.
Project Member Comment 37 by, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 38 by, Mar 9 2013
Labels: -Type-Regression -Area-WebKit -WebKit-Editing -WebKit-Forms -Mstone-17 Cr-Content Type-Bug-Regression Cr-Content-Forms Cr-Content-Editing M-17
Project Member Comment 39 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 40 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Project Member Comment 41 by, Apr 6 2013
Labels: -Cr-Content-Editing Cr-Blink-Editing
Project Member Comment 42 by, Apr 6 2013
Labels: -Cr-Content-Forms Cr-Blink-Forms
Sign in to add a comment