Bug 11423 - REGRESSION: First newline missing from textarea's value
Summary: REGRESSION: First newline missing from textarea's value
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Nobody
URL:
Keywords: Regression
Depends on:
Blocks:
 
Reported: 2006-10-26 07:36 PDT by mitz
Modified: 2006-10-27 15:14 PDT (History)
1 user (show)

See Also:


Attachments
Test case (191 bytes, text/html)
2006-10-26 07:38 PDT, mitz
no flags Details
patch (30.08 KB, patch)
2006-10-26 19:31 PDT, Justin Garcia
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2006-10-26 07:36:48 PDT
The first newline in a textarea isn't included in the value when submitted or accessed via the value property.

See the attached test case.
Comment 1 mitz 2006-10-26 07:38:01 PDT
Created attachment 11225 [details]
Test case

When you click Test, the words in the alert box should be on seaprate lines. In TOT, the first two words are one the same line with no space between them.
Comment 2 Justin Garcia 2006-10-26 15:58:24 PDT
Sounds like this might have been caused by my TextIterator changed.  Checking.
Comment 3 Justin Garcia 2006-10-26 16:22:35 PDT
This regressed between 17205 and 17233.  My change in 17223 seems most likely.
Comment 4 Justin Garcia 2006-10-26 16:23:13 PDT
...although, it didn't touch serialization. 
Comment 5 Justin Garcia 2006-10-26 16:34:06 PDT
It was definitely my changes in r17223 that caused this.  

Before, when inserting a line break after the first paragraph, 'foo', we'd insert a '\n' (because the text is white-space:pre, and then we'd insert an extra br so that the '\n' would hold its own line open, and the extra br was inserted after the '\n'.  Now the br is inserted before the '\n', and so it is the '\n' that is displaced by 'bar', leaving the br to break the line, whereas before it was the br that was displaced, and '\n' held open the line.  Apparently, there is a serialization bug that leaves out brs.

The quick fix is to, in InsertLineBreakCommand, use the same type of node that we used for the line break in the case that that break collapsed because it was inserted at the end of a block.
Comment 6 Justin Garcia 2006-10-26 19:31:25 PDT
Created attachment 11231 [details]
patch
Comment 7 mitz 2006-10-27 05:02:30 PDT
Comment on attachment 11231 [details]
patch

Justin, did you intentionally not set the review flag?
Comment 8 Justin Garcia 2006-10-27 14:02:13 PDT
harrison reviewed this and I checked it in in r17386.
Comment 9 David Kilzer (:ddkilzer) 2006-10-27 14:21:02 PDT
Comment on attachment 11231 [details]
patch

>Index: WebCore/ChangeLog
>===================================================================
>--- WebCore/ChangeLog	(revision 17351)
>+++ WebCore/ChangeLog	(working copy)
>@@ -1,3 +1,40 @@
>+2006-10-26  Justin Garcia  <justin.garcia@apple.com>
>+
>+        Reviewed by NOBODY (OOPS!).
>+        
>+        <http://bugs.webkit.org/show_bug.cgi?id=11423>
>+        REGRESSION: First newline missing from textarea's value
>+        
>+        The regression is that foo, return, bar in a textarea serializes as 'foobar'.
>+        
>+        Before my change in r11423, return (an InsertLineBreak) would insert '\n' (the
>+        line break) then a br to prevent a collapse, since the insertion is being done
>+        at the end of a block (the textarea's shadow div).  Then, inserting "bar" would 
>+        displace the br, and "foo\nbar" would serialize as "foo\nbar".  After my change 
>+        in r11423, InsertLineBreak would insert a br then a '\n' (reversed the order).  
>+        Then inserting "bar" would displace the '\n' and "foo"<br>"bar" would serialize as 
>+        "foobar" because when serializing RenderTextControl intentionally asks textContent 
>+        to not convert brs to newlines.  It seems to think that the only brs in the shadow
>+        div will be placeholders.

Justin, don't you mean "r17223" (per Comment #5) above instead of "r11423"?
Comment 10 Justin Garcia 2006-10-27 15:14:21 PDT
 
> Justin, don't you mean "r17223" (per Comment #5) above instead of "r11423"?

Oops.  Fixed.  Thanks.