I used a hidden form input field to pass a string. The string contained "\r\n" sequences which were transformed to "\r\r\n" when I read the value of the form field on the next page. Sorry, but I don't have a demo page as the fom belongs to a restricted area with database querys. The querys do not work as the "\r\r\n" is only "\r\n" in the database.

Reporter what build id are you using? Also do you have a testcase we can use? Otherwise we cant do much with this bug

I used Mozilla Milestones 0.92 and now I tried 0.93. The error occurs in 0.92 and 0.93 but there was no error in 0.91. I'm trying to get a demo page to work, but that's difficult since you have to save the result in a text file and view it with a HEX Editor to see the additional CR. It's just that way that I pass a string in a hidden form field to perform a database search on the next page. The database search fails if the string contains a CR/LF as this is transformed to CR/CR/LF and so the result isn't found in the database. As I already said I'll try to get a demo page to work. Thanx for the reply so far.

Now I wrote a demo page for demonstrating the bug. Hopefully this helps you. The URL to the demo page is http://www.shooterzone.de/mozbugdemo/mozbug_demo.php

Bug confirmed. Not sure whether this belongs to the editor, form submission, or html form controls, but leaving here in the mean time. Is it possible to get someone to look at this and reassign if needed? Thanks! Tested on mozilla0.9.3 win2k.

->>

There's no editor involved here giving to form submision: --> alexsavulov@netscape.com

i tested with some simple PHP and HTML scripts (including javascript setting) and it works for me. i couldn't reproduce the problem on the server side. there are no additional r\'s an the server. i will attach the scripts used to this bug. reporter: please check them out and tell us if the test cases are touching the problem described by you.

this php script was served by a linux/apache/php server

ther are two hidden fields, the second one's value is set by javascript. (edited with homesite 5.2)

TEST RESULTS: (generated with the first tow attached scripts) Values submitted via POST method: There were 3 instances of " " (ASCII 10) in the string. There were 3 instances of " " (ASCII 13) in the string. There were 32 instances of "." (ASCII 46) in the string. testinput = ........%#........%#........%#........ There were 3 instances of " " (ASCII 10) in the string. There were 3 instances of " " (ASCII 13) in the string. There were 32 instances of "." (ASCII 46) in the string. testinputjavascript = ........%#........%#........%#........

I do also get an OK result when testing it with your script. But when I change your script like this <?php $value="........\r\n\r........\r\n........\r\n........"; echo "<input type=\"hidden\" name=\"testinput\" value=\"" . $value . "\">"; ?> to be able to add and remove CR/LF characters I do get the following results with Mozilla and Opera 6. The Opera 6 result looks like I expected it to look. But Mozilla again added a character (this time a LF). -------- Mozilla: Values submitted via POST method: There were 4 instances of " " (ASCII 10) in the string. There were 4 instances of " " (ASCII 13) in the string. There were 32 instances of "." (ASCII 46) in the string. testinput = ........%#%#........%#........%#........ There were 3 instances of " " (ASCII 10) in the string. There were 3 instances of " " (ASCII 13) in the string. There were 32 instances of "." (ASCII 46) in the string. testinputjavascript = ........%#........%#........%#........ -------- Opera 6: Values submitted via POST method: There were 3 instances of " " (ASCII 10) in the string. There were 4 instances of " " (ASCII 13) in the string. There were 32 instances of "." (ASCII 46) in the string. testinput = ........%#%........%#........%#........ There were 3 instances of " " (ASCII 10) in the string. There were 3 instances of " " (ASCII 13) in the string. There were 32 instances of "." (ASCII 46) in the string. testinputjavascript = ........%#........%#........%#........ --------- This again breaks string comparison when using the string from the hidden form field. You can find the script I used at http://www.shooterzone.de/mozbugdemo/test1.php I used Mozilla Milestone 0.97 (Build 2001122106) for testing.

So we're translating \r into \r\n? Perhaps we should update the summary to reflect?

This bug is critical for people using Oracle Designer Web Pl/Sql modules with multi-line input fields (database update fails).

John: from comment 11 i think that we screw (intelligent correction?) that when we encounter \r\n\r not when we submit but when we initialize the form controls. We should take a look after you land the big nsIFormSubmission change as soon as we get some time. This one looks pretty severe.

Why no activity on this bug ? Is it going to be fixed in Mozilla 1.0 ? -- peter

*** Bug 182474 has been marked as a duplicate of this bug. ***

So.. I have no idea what that test page at http://www.shooterzone.de/mozbugdemo/mozbug_demo.php is doing -- the input fields do NOT contain any \r chars (tested with wget). As for the pages attached here, \r is not a valid character in the DOM. The parser will never generate a DOM containing \r. Doing so by hand leads to undefined behavior, as you see here (since all code manipulating a DOM knows that the only newlines in there are \n).

But \r is is valid in form parameters. In the bug Bug 182474 there is a test http://bugzilla.mozilla.org/attachment.cgi?id=107725&action=view showing that wrong number of \r go to URL.

> But \r is is valid in form parameters. Actually, I don't think it is..... All newlines in the DOM, including in attribute values, must be normalized to \n. The fact that we don't do that for &#10; is a bug (and we have a report on it).

For input text fields probably yes. For hidden fields - I am not sure. There is nothing about this in HTML specification. http://www.w3.org/TR/html401/interact/forms.html Most people expect any binary data being OK in "hidden" type of INPUT element.

> Most people expect any binary data being OK in "hidden" type of INPUT element. Do they? There's no way that can work, since that stores _characters_ and not bytes. There is no browser I am aware of in which "any binary data" is OK in there. Nor should there be. As for the HTML specification, it's pretty useless as far as what it specifies....

Marking invalid, since we are in fact doing exactly what we should be....