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: | P2 | Keywords: | Regression | ||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Bug Depends on: | 54598 | ||||||||||
Bug Blocks: | |||||||||||
Attachments: |
|
Description
Peter Braden
2011-05-25 16:49:02 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. 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. |