Bug 14941 – REGRESSION: textarea value from JavaScript includes extra newline

• Component: Forms
• Status: RESOLVED FIXED

[Michael A. Puls II]

In WebKit r24872, pressing enter on a non-empty line in a textarea adds two newlines to the DOM value (not visually) instead of one. No other browser does this. This causes double %0D%0A in the encoded value after pressing enter.

Also, pressing the insert key in a textarea inserts null bytes into the DOM value.

[Michael A. Puls II]

Created attachment 15929 [details]
Demo

[Michael A. Puls II]

(In reply to comment #0)
>This causes double %0D%0A in the encoded value after pressing enter.

At the URI listed above I mean. 

[David Kilzer (:ddkilzer)]

Confirmed with a local debug build of WebKit r25008 with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218).

[David Kilzer (:ddkilzer)]

<rdar://problem/5404093>

[David Kilzer (:ddkilzer)]

BTW, excellent test case, Michael!

[Cameron Zwarich (cpst)]

I did some hunting with nightlies. This bug wasn't introduced all at once. Here is an exciting timeline of these problems. I can't test the insert bug, so it is excluded.

Before the r14941 nightly (the last nightly prior to that is r14926), all is well. With the r14941 nightly, the following problems are introduced:

1) The phantom newline after deleting text that contains a newline.

2) Typing "line1" and then enter does not actually display a newline, it only adds an invisible one to the value of the textarea. When you hit enter again, there are two newlines.

There are two revisions between these nightlies that affect the textarea element, r14931 <http://trac.webkit.org/projects/webkit/changeset/14931> and r14935 <http://trac.webkit.org/projects/webkit/changeset/14935>. My money is on r14931, but I don't have the bandwidth right now to download a tree to test.

I noticed that at some point in time, both of these bugs were fixed. I tracked it down to the period between the nightlies r15614 and r15618, surely by r15617 <http://trac.webkit.org/projects/webkit/changeset/15617>.

The phantom newline after delete was reintroduced between the nightlies r17205 and r17233. The most likely candidate for introduction is r17223 <http://trac.webkit.org/projects/webkit/changeset/17223>.

Finally, the phantom newline after hitting enter was introduced by r17386 <http://trac.webkit.org/projects/webkit/changeset/17386> (I had a tree from that day sitting around from another bug fix).

I am not sure I will have the time to put together a patch to fix all of these problems in the next week, because I'm at a conference, but hopefully this will help anyone who is trying to fix it.

[John Sullivan]

What user symptoms are caused by these problems?

[Michael A. Puls II]

With textarea counter scripts that limit the length of input, the stray newline and extra newlines decrease the limit of real text and lines you can input.

If you press insert and it enters null bytes, those are counted by textarea counters also. In fact, if you hold down insert, you can exhaust your limit even though the textarea still looks blank.  A user could unknowingly decrease their limit.

With the stray newline (once triggered), it makes it difficult (if you don't know about the bug) to submit a textarea with an empty value to the server.

The extra newlines are also submitted to the server causing an incorrect value to be submitted. If the server script takes each newline pair and converts it to <p></p> for example, you'll get an extra <p></p> with this problem, which would produce the wrong output in whatever was using the them.

With my jsuri composer, it causes the js uri to have 6 extra bytes for every stray newlinee and 3 for every null byte. This causes the js URI to be longer than other browsers and when the textarea produces null bytes and causes %00 to be in the js uri, the js uri will be broken. (I can filter out the null bytes, but the extra newlines produced I cannot because I can't differentiate them from non-extra ones.)

In SquirrelMail, if you hit insert, this can cause the outgoing body to get cut off at the null byte. This breaks Gmail in the same way. It probably breaks other webmails in the same way.

(In reply to comment #7)
> What user symptoms are caused by these problems?
> 
In short, they break form submission.

See also bug 14562.

[David Kilzer (:ddkilzer)]

Using autospade (Bug 15002):

Works: r17205  Fails: r17233

Note that the behavior in r17233 is different from ToT when using the test case (Attachment #15929 [details]).  Hitting Enter adds a %0A character ("line1%0A"), but then typing "a" puts it BEFORE the return character ("line1a%0A") instead of after it!  In later revisions, you end up with "line1%0Aa".  In both cases, the "%0A" character is undeletable.

[David Kilzer (:ddkilzer)]

Behavior changed again between r17354 ("line1a%0A") and r17388 ("line1%0Aa").

[David Kilzer (:ddkilzer)]

(In reply to comment #11)
> Behavior changed again between r17354 ("line1a%0A") and r17388 ("line1%0Aa").

Likely r17386:  http://trac.webkit.org/projects/webkit/changeset/17386

(In reply to comment #10)
> Works: r17205  Fails: r17233

Likely r17223:  http://trac.webkit.org/projects/webkit/changeset/17223

[Darin Adler]

It's a mistake to have two bugs both reported in the same bug report. I have a fix for the multiple newline one, but since my keyboard doesn't even have an insert key in it I'm not going to be able to fix the other.

(In reply to comment #13)
> Since my keyboard doesn't even have an
> insert key in it I'm not going to be able to fix the other.

I am pretty sure the insert key bug is bug 14562 has been fixed long ago in <http://trac.webkit.org/projects/webkit/changeset/25251>.

[Michael A. Puls II]

(In reply to comment #14)
> (In reply to comment #13)
> > Since my keyboard doesn't even have an
> > insert key in it I'm not going to be able to fix the other.
> 
> I am pretty sure the insert key bug is bug 14562 has been fixed long ago in
> <http://trac.webkit.org/projects/webkit/changeset/25251>.
> 

Yep,  the insert key no longer inserts null bytes. Just need the newline fix now.

[Darin Adler]

Created attachment 19805 [details]
patch

Comment on attachment 19805 [details]
patch

r=me

[Darin Adler]

Committed revision 31081.