Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 106551 Pasting text into a single-line text field shouldn't keep literal newlines
Starred by 20 users Reported by j...@stikman.com, Dec 6 2011 Back to list
Status: Verified
Owner:
User never visited
Closed: Feb 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 0
Type: Bug-Regression

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
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
possible.

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.
 
Capture.PNG
2.5 KB View Download
Comment 1 by tkent@chromium.org, Dec 6 2011
Cc: dcheng@chromium.org
Labels: -Area-Undefined Area-WebKit WebKit-Editing WebKit-Forms
Comment 2 by gconk...@gmail.com, 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 dcheng@chromium.org, 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 tkent@chromium.org, 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 dcheng@chromium.org, 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 tkent@chromium.org, 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:
abc
def
ghi
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 http://trac.webkit.org/browser/trunk/Source/WebCore/html/TextFieldInputType.cpp#L334
I'm don't know why this problem happens.

Comment 7 by gconk...@gmail.com, Jan 16 2012
I would say http://code.google.com/p/chromium/issues/detail?id=110183 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 gconk...@gmail.com, 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 dcheng@chromium.org, Jan 17 2012
 Issue 110183  has been merged into this issue.
As I said in the duplicated and closed http://code.google.com/p/chromium/issues/detail?id=110183  this worked correctly in other browsers: Firefox, IE, Safari, both in Mac and PC, and using both MS Excel and OpenOffice.org 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


screenspreadpaste.JPG
7.9 KB View Download
Comment 11 Deleted
Comment 12 by tkent@chromium.org, Feb 13 2012
 Issue 113623  has been merged into this issue.
Comment 13 by tkent@chromium.org, Feb 13 2012
Labels: -Pri-2 Pri-1
Owner: rniwa@chromium.org
Status: Assigned
I confirmed this regression was caused by:
http://trac.webkit.org/changeset/99076/  div { display: none; } makes pasting into text fields impossible


Comment 14 by tkent@chromium.org, Feb 14 2012
 Issue 113988  has been merged into this issue.
Comment 15 by rniwa@chromium.org, Feb 14 2012
I'm going to look into this issue later today.
Comment 16 by rniwa@chromium.org, Feb 19 2012
Cc: kareng@google.com komoroske@chromium.org
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 tkent@chromium.org, Feb 23 2012
Cc: tkent@chromium.org
 Issue 115096  has been merged into this issue.
Comment 18 by tkent@chromium.org, Feb 23 2012
Labels: WebKit-ID-79305
Project Member Comment 19 by bugdroid1@chromium.org, Feb 23 2012
Labels: -WebKit-ID-79305 WebKit-ID-79305-NEW
https://bugs.webkit.org/show_bug.cgi?id=79305
Comment 20 by rniwa@chromium.org, Feb 23 2012
I've posted a WebKit patch.
Comment 21 by gconk...@gmail.com, 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 bugdroid1@chromium.org, Feb 23 2012
Labels: -WebKit-ID-79305-NEW WebKit-ID-79305-RESOLVED
https://bugs.webkit.org/show_bug.cgi?id=79305
Comment 23 by rniwa@chromium.org, Feb 23 2012
Should be fixed in Should be fixed in http://trac.webkit.org/changeset/108668.
Comment 24 by rniwa@chromium.org, 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 bugs.webkit.org.
Comment 25 by gconk...@gmail.com, 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 tkent@chromium.org, Feb 27 2012
 Issue 115642  has been merged into this issue.
Comment 27 by tkent@chromium.org, Feb 27 2012
 Issue 115778  has been merged into this issue.
Comment 28 by tkent@chromium.org, Feb 27 2012
Labels: Merge-Requested
Status: Verified
Verified this was fixed with 19.0.1053.0 canary.

Comment 29 by tkent@chromium.org, Feb 27 2012
Labels: ReleaseBlock-Stable
Comment 30 by k...@google.com, Feb 27 2012
Labels: -Merge-Requested -ReleaseBlock-Stable Merge-Approved
Not a blocker, but ok to merge.
Comment 31 by rniwa@chromium.org, Feb 27 2012
Merged into 963 branch in http://trac.webkit.org/changeset/109012.
Comment 32 by tkent@chromium.org, Feb 29 2012
@rniwa, Would you merge the fix to 1025 branch too?

Comment 33 by rniwa@chromium.org, Feb 29 2012
Sure.  Done in http://trac.webkit.org/changeset/109272.
Labels: -Merge-Approved Merge-Merged
Comment 35 by gconk...@gmail.com, Mar 12 2012
For completeness, I finally created the "trailing space" issue in the webkit bugzilla and just noting it here for informational purposes.

https://bugs.webkit.org/show_bug.cgi?id=80838
Comment 36 by tkent@chromium.org, Mar 13 2012
 Issue 117506  has been merged into this issue.
Project Member Comment 37 by bugdroid1@chromium.org, 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 bugdroid1@chromium.org, 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 bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 40 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Project Member Comment 41 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content-Editing Cr-Blink-Editing
Project Member Comment 42 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content-Forms Cr-Blink-Forms
Sign in to add a comment