Bug 61483

Summary:

Textarea will not accept space characters at end of line

Product:

WebKit

Reporter:

Peter Braden <peterbraden>

Component:

HTML Editing

Assignee:

Ryosuke Niwa <rniwa>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

alexander.a.cabal, ap, enrica, peterbraden, rniwa

Priority:

Keywords:

Regression

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Bug Depends on:

54598

Bug Blocks:

Attachments:

Description	Flags
test case	none
adds a regression test	ap: review+
demo (bug on Safari 5, works on ToT)	none

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+	Details Formatted Diff Diff
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.