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.
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.
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.
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.
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 ***
This is a regression, so it's not a duplicate of bug bug 54598.
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?
Not any time soon, sorry.
(In reply to comment #7) > Not any time soon, sorry. Okay. Let me try then.
Created attachment 97210 [details] adds a regression test
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?
(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.
The regression part is that although spaces were not visible in Safari 5, they were inserted to DOM.
(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.
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.
Comment on attachment 97210 [details] adds a regression test Either way, this is clearly good to land.
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.
As noted in comments above, this isn't a regression after all. Only the exact condition by which the bug manifests changed over time.
Committed r88946: <http://trac.webkit.org/changeset/88946>
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.
(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.