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 link

Starred by 20 users

Issue metadata

Status: Verified
Owner:
Email to this user bounced
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

Pasting text into a single-line text field shouldn't keep literal newlines

Reported by j...@stikman.com, Dec 6 2011

Issue description

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
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