RESOLVED FIXED 61483
Textarea will not accept space characters at end of line 
https://bugs.webkit.org/show_bug.cgi?id=61483
Summary Textarea will not accept space characters at end of line
Peter Braden
Reported 2011-05-25 16:49:02 PDT
Overview: Typing space at the end of a line with certain character combinations will not insert a space and wrap. Additionally, after typing other characters which cause the line to wrap, the space character will be omitted. Additionally, after problematically inserting a space, then retyping space, the extra space will disappear. Steps to Reproduce: This is a really interesting bug because it happens with a bunch of different words in the line, but is inconsistent. I have managed to find a consistent repro case though. 1) With a html page as follows: <html> <head /> <body> <textarea style="height: 34px; width: 535px;"></textarea> </body> </html> 2) Edit the textarea to contain as many 'a' characters as takes to fill the line (another a would make it wrap) 3) Delete the last 'a' and add an 'l' character. The line should not wrap. 4) Try and add a space character - notice the line does not wrap. 5) You can try and add as many space characters as you like - they are not added to the val, and the textarea won't wrap. 6) Add another non space character. The line will wrap, however arrowing back will confirm the space character was not added. 7) Notice that adding space characters problematically, then repeating steps, truncates trailing spaces to a single space. Expected Results: - Space characters will make the line wrap - Space characters should be able to be added at the end of lines. Build Date & Platform: Repro'd on Chrome, Safari, and the nightly WebKit r87281 built on 25 May 2011. Only tested on OSX thus far.
Attachments
test case (1.03 KB, text/html)
2011-05-26 11:29 PDT, Alexey Proskuryakov 		no flags
Details
adds a regression test (2.35 KB, patch)
2011-06-14 18:21 PDT, Ryosuke Niwa 		ap: review+
DetailsFormatted DiffDiff
demo (bug on Safari 5, works on ToT) (741 bytes, text/html)
2011-06-15 07:18 PDT, Ryosuke Niwa 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2011-05-25 23:12:49 PDT
This behavior is very similar to what TextEdit has, and thus likely intentional. I do not know what the rationale is. Note that all the spaces are inserted - they just do not cause formatting changes, but if you resize the text area, they will appear. Similarly, they are sent with form submission and when copying into clipboard.
Peter Braden
Comment 2 2011-05-26 10:46:39 PDT
The main bug is that the spaces are _not_ inserted - programatic inspection or additional non-space character insertion shows that the spaces are not there. I also disagree that this behaviour is expected - the other browsers handle this by wrapping on space, as do many other apps - textedit likely has this behavior because it may use webkit under the covers? I have several users who have reported this as a bug, reinforcing the view that the behaviour is unexpected. Best, P (In reply to comment #1) > This behavior is very similar to what TextEdit has, and thus likely intentional. I do not know what the rationale is. > > Note that all the spaces are inserted - they just do not cause formatting changes, but if you resize the text area, they will appear. Similarly, they are sent with form submission and when copying into clipboard.
Alexey Proskuryakov
Comment 3 2011-05-26 11:29:00 PDT
Created attachment 95010 [details] test case > The main bug is that the spaces are _not_ inserted - programatic inspection or additional non-space character insertion shows that the spaces are not there. Oh, I see that now. the reason I didn't see it before is that's a regression from Safari 5 to nightly builds. In Safari 5, spaces are inserted, but visually it looks the same. > textedit likely has this behavior because it may use webkit under the covers? It does not.
Ryosuke Niwa
Comment 4 2011-05-26 11:34:19 PDT
This is caused by the bug 54598. VisiblePosition is canonicalized before the space and disallowing any space be inserted at the end of line. *** This bug has been marked as a duplicate of bug 54598 ***
Alexey Proskuryakov
Comment 5 2011-05-26 11:49:10 PDT
This is a regression, so it's not a duplicate of bug bug 54598.
Ryosuke Niwa
Comment 6 2011-06-14 17:23:20 PDT
I have confirmed that http://trac.webkit.org/changeset/88883 fixed this bug as well. ap, would you be interesting in making a DRT test that works on all ports/platform for this bug?
Alexey Proskuryakov
Comment 7 2011-06-14 17:31:19 PDT
Not any time soon, sorry.
Ryosuke Niwa
Comment 8 2011-06-14 17:32:25 PDT
(In reply to comment #7) > Not any time soon, sorry. Okay. Let me try then.
Ryosuke Niwa
Comment 9 2011-06-14 18:21:55 PDT
Created attachment 97210 [details] adds a regression test
Alexey Proskuryakov
Comment 10 2011-06-14 22:23:57 PDT
When I run this test in Safari 5.0.5 (which presumably didn't have this bug), the test says FAIL. Am I just confused, or does the test not capture the regression aspect of this problem?
Ryosuke Niwa
Comment 11 2011-06-14 22:50:33 PDT
(In reply to comment #10) > When I run this test in Safari 5.0.5 (which presumably didn't have this bug), the test says FAIL. Am I just confused, or does the test not capture the regression aspect of this problem? Okay, I don't believe that this is a regression anymore. I can reproduce the exact bug on Safari 5. Just insert many 'a' as possible in the attached demo, and insert one space. You can't insert any more spaces after that.
Alexey Proskuryakov
Comment 12 2011-06-14 22:58:46 PDT
The regression part is that although spaces were not visible in Safari 5, they were inserted to DOM.
Ryosuke Niwa
Comment 13 2011-06-14 23:20:36 PDT
(In reply to comment #12) > The regression part is that although spaces were not visible in Safari 5, they were inserted to DOM. That behavior is not reproducible at least on my MBP when I insert "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa " on the attached document. I can't insert anymore spaces after the space at the end.
Alexey Proskuryakov
Comment 14 2011-06-15 00:53:51 PDT
Please try steps to reproduce form the original description (fill the line with aaa's, delete the last one, type l, then press space multiple times). That's a regression. However, given your example, it's probably some small inconsequential change that caused it. Quite mysterious though.
Alexey Proskuryakov
Comment 15 2011-06-15 00:54:22 PDT
Comment on attachment 97210 [details] adds a regression test Either way, this is clearly good to land.
Ryosuke Niwa
Comment 16 2011-06-15 07:18:19 PDT
Created attachment 97290 [details] demo (bug on Safari 5, works on ToT) (In reply to comment #14) > Please try steps to reproduce form the original description (fill the line with aaa's, delete the last one, type l, then press space multiple times). That's a regression. > > However, given your example, it's probably some small inconsequential change that caused it. Quite mysterious though. Right, but this is purely due to font-metric difference / line layout difference. In this new demo, the exact bug described in this bug reproduces on Safari 5 but does not reproduce on ToT WebKit.
Ryosuke Niwa
Comment 17 2011-06-15 09:18:51 PDT
As noted in comments above, this isn't a regression after all. Only the exact condition by which the bug manifests changed over time.
Ryosuke Niwa
Comment 18 2011-06-15 09:28:54 PDT
Committed r88946: <http://trac.webkit.org/changeset/88946>
Alex Cabal
Comment 19 2011-07-01 23:10:53 PDT
Just wanted to pop in and mention that this bug isn't limited to textareas. Users of my web app ran into this problem with spans that have contenteditable="true" that wrap to a new line. If you have a span with contenteditable="true" nested within a div and then try to enter a space at the point where the span will wrap to a newline, this bug appears too: that is, the previous word in the span will wrap down, the space will disappear, and the previous word will run in to the new word you're tying because the space disappeared. I can't download the nightly to test that it's been fixed for contenteditables as well, but I just wanted you to be aware that this bug isn't limited to textareas. I can provide more information if necessary.
Ryosuke Niwa
Comment 20 2011-07-01 23:20:18 PDT
(In reply to comment #19) > Just wanted to pop in and mention that this bug isn't limited to textareas. Users of my web app ran into this problem with spans that have contenteditable="true" that wrap to a new line. > > If you have a span with contenteditable="true" nested within a div and then try to enter a space at the point where the span will wrap to a newline, this bug appears too: that is, the previous word in the span will wrap down, the space will disappear, and the previous word will run in to the new word you're tying because the space disappeared. > > I can't download the nightly to test that it's been fixed for contenteditables as well, but I just wanted you to be aware that this bug isn't limited to textareas. I can provide more information if necessary. Yes, I'm fully aware of that. r88883 should have fixed that as well.
Note You need to log in before you can comment on or make changes to this bug.