256027 - <input> form type=text - default values are truncated if source contains a newline

Status: RESOLVED WORKSFORME

(Core :: DOM: HTML Parser, defect)

Description

[PJM]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040817
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040817


When a form has a single-line text input box, with a default value containing a
newline, the default value gets truncated at the newline when the form is displayed.

For example, this displays fine:

<form>
<input type=text value="Good">
</form>

But for the following, the text gets truncated at "Not so".

<form>
<input type=text value="Not so
good">
</form>

The parser is either clipping the attribute at the newline, or perhaps the
newline is being retained, and the second part of the value is being displayed
off the bottom of the text box?

According to the HTML spec, the value attribute is type CDATA, which should be
being rendered by ignoring linefeeds and converting carriage returns into
spaces.  Therefore, I would expect to see the whole line appear in the box.

Note that newlines elsewhere in the form have no effect.  For example, this
works perfectly:

<form>
<input 
type=text 
value="Not so good"
>
</form>

Reproducible: Always
Steps to Reproduce:
1.Copy the examples from the "details" above into a blank text file.
2.Open text file in Mozilla.
3.Witness the bug!

Actual Results:  
I witnessed the bug - the line in the text box came out as "Not so"

Expected Results:  
The line should have come out as "Not so good"

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is already filed.  The point is, there is no "right" way to do this.

Comment 2

[PJM]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3)
Gecko/20040817
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3)
Gecko/20040817
> 
> 
> When a form has a single-line text input box, with a default value containing a
> newline, the default value gets truncated at the newline when the form is
displayed.
> 
> For example, this displays fine:
> 
> <form>
> <input type=text value="Good">
> </form>
> 
> But for the following, the text gets truncated at "Not so".
> 
> <form>
> <input type=text value="Not so
> good">
> </form>
> 
> The parser is either clipping the attribute at the newline, or perhaps the
> newline is being retained, and the second part of the value is being displayed
> off the bottom of the text box?
> 
> According to the HTML spec, the value attribute is type CDATA, which should be
> being rendered by ignoring linefeeds and converting carriage returns into
> spaces.  Therefore, I would expect to see the whole line appear in the box.
> 
> Note that newlines elsewhere in the form have no effect.  For example, this
> works perfectly:
> 
> <form>
> <input 
> type=text 
> value="Not so good"
> >
> </form>
> 
> Reproducible: Always
> Steps to Reproduce:
> 1.Copy the examples from the "details" above into a blank text file.
> 2.Open text file in Mozilla.
> 3.Witness the bug!
> 
> Actual Results:  
> I witnessed the bug - the line in the text box came out as "Not so"
> 
> Expected Results:  
> The line should have come out as "Not so good"

(In reply to comment #1)
> This is already filed.  The point is, there is no "right" way to do this.

Hi - is this bug already in bugzilla?  I searched quite throughly but couldn't
find it.  I'd appreciate a pointer to it if possible so I can follow the debate.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Please refer to bug 15204 (which I'm marking this a DUPLICATE of). The part that
this bug addresses is addressed starting at comment 53.

*** This bug has been marked as a duplicate of 15204 ***

Comment 4

[PJM]

This bug needs to be reopened, because it is not fixed - the test page is still
being parsed incorrectly in Mozilla 1.7 (and Firefox 1.0).

Therefore, I do not believe that this bug is a duplicate of 15204, as this was
apparently fixed in M18.

The bug occurs when you get a newline in the default value of a "form type=text"
element.  At the moment, this causes the default value to be truncated at the
newline - anything following the newline is lost.  
The HTML spec for CDATA suggests that newlines ought to be replaced with spaces
- this would have the effect of bringing all the lines of the default value up
onto one line, and thus no truncation would occur.  To make things clearer, demo
HTML is given at the end of this post.

The bug particularly afflicts the popular "AtMail" web-mail application, causing
lists of addresses to get truncated when you hit reply-to-all on an email. 
Currently I need to switch over to IE6.0 to use my web-mail!

As I mention, these newlines in default values to not affect IE6.0 - it
successfully merges the lines onto a single line.  Therefore I reckon this is a
bug with *quirks mode*, as it is failing to properly emulate IE6.0 (and the
Atmail pages have no DocType).

Demonstration code fragments follow - you can paste these into a text file and
point your browser to see the effect...

This code gives the correct page in Mozilla and IE6.0:

<html><body>
<input type="text" size="60" value="[e-mail], [e-mail]">
</body></html>

Whereas, this code works in IE6.0, but not in Mozilla, where the second email
address in the list gets lost:

<html><body>
<input type="text" size="60" value="[e-mail], 
[e-mail]">
</body></html>

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[David Ross]

I can confirm this bug still exists (or has reappeared) in Mozilla 1.7.12.  I
get the same results on Linux (RH9) and Windows 98.  This happens in quirks and
strict mode, tested by changing the doctype.

One extra note is that on Linux the data is still in the input box and it is
possible to scroll up and down it, this is not possible on Windows.

Comment 7

[Steuard Jensen]

Attachment: Testcase based on reporter's example

Comment 8

[Steuard Jensen]

Confirming, and attaching a testcase.  This bug is closely related to work being done on bug 114997 and bug 322270 regarding how to handle newlines in "value" (and other) attributes.  However, it seems likely to me that we should be stripping newlines for text inputs in general, considering the observation here that they do lots of harm and no good.

Comment 9

[Steuard Jensen]

In bug 114997 comment 62, I've outlined what to my (inexpert) eye looks like a complete fix to this bug (marginally more thorough than a fix to bug 322270 would be, and certainly much simpler).  A text input's value is determined in nsHTMLInputElement.cpp: the nsHTMLInputElement::GetValue() function gets it from source or from the text editor, and the nsHTMLInputElement::SetValueInternal() function sets it from Javascript.

If unwanted whitespace characters (newlines and tabs) are listed as the string "kWhitespace", then all we need to do in both places is the moral equivalent of the regular expression substitution "s/[kWhitespace]+/ /g" (though a non-regex implementation would probably be more efficient, and the '+' is debatable but would eliminate inconsistencies in platform linebreaks).  In Javascript, regex handling is built in, but this is C++, and I haven't been able to locate any existing function for Mozilla's string classes that would do this.  (There are some similar functions in nsStringObsolete.cpp and nsTStringObsolete.cpp, but that file names don't inspire confidence, and none are a perfect match.)

I could easily write a little routine to do it myself, but 1) I'm having trouble believing that this code isn't already out there, since this sort of functionality seems broadly useful, and 2) I'd probably write something painfully inefficient due to lack of experience.  (Also, I'd feel weird embedding a generally useful function like this into the forms code rather than somewhere where it could be reused.)  If anyone can point me to an existing function that fits the bill, please do so!

Comment 10

[Henri Sivonen (:hsivonen)]

WFM.