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.
Created attachment 15929 [details] Demo
(In reply to comment #0) >This causes double %0D%0A in the encoded value after pressing enter. At the URI listed above I mean.
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).
<rdar://problem/5404093>
BTW, excellent test case, Michael!
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.
What user symptoms are caused by these problems?
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.
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.
Behavior changed again between r17354 ("line1a%0A") and r17388 ("line1%0Aa").
(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
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>.
(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.
Created attachment 19805 [details] patch
Comment on attachment 19805 [details] patch r=me
Committed revision 31081.