[Webkit-unassigned] [Bug 14941] REGRESSION: textarea value storage implementation is buggy with newlines and null bytes

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=14941





------- Comment #8 from shadow2531 at gmail.com  2007-08-13 23:07 PDT -------
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.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.