92728 - hidden form field transforms CR/LF to CR/CR/LF[form sub]

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect, P3)

Description

[fuzzi]

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.

Comment 1

[Keyser Sose]

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

Comment 2

[fuzzi]

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.

Comment 3

[fuzzi]

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

Comment 4

[Fabian Guisset]

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.

Comment 5

[rods (gone)]

->>

Comment 6

[kinmoz]

There's no editor involved here giving to form submision:

--> [e-mail]

Comment 7

[Alexandru Savulov]

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.

Comment 8

[Alexandru Savulov]

Attachment: the php script used in my test

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

Comment 9

[Alexandru Savulov]

Attachment: the HTML script used in my test

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

Comment 10

[Alexandru Savulov]

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 = ........%#........%#........%#........

Comment 11

[fuzzi]

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.

Comment 12

[John Keiser (jkeiser)]

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

Comment 13

[Peter Nybo Rasmussen]

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

Comment 14

[Alexandru Savulov]

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.

Comment 15

[Peter Nybo Rasmussen]

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

Comment 16

[Alistair Y. Lewars]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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).

Comment 18

[Vladislav Malyshkin]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

> 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

 is a bug (and we have a report on it).

Comment 20

[Vladislav Malyshkin]

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.

Comment 21

[Boris Zbarsky [:bzbarsky]]

> 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....

Comment 22

[Boris Zbarsky [:bzbarsky]]

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