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

RESOLVED INVALID

Status

()

P3
major
RESOLVED INVALID
18 years ago
15 years ago

People

(Reporter: fuzzi, Assigned: alexsavulov)

Tracking

({qawanted})

Trunk
mozilla1.2alpha
x86
Windows 98
qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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

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

Comment 2

18 years ago
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.
(Reporter)

Comment 3

18 years ago
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

18 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

17 years ago
->>
Assignee: rods → kin

Comment 6

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

--> alexsavulov@netscape.com
Assignee: kin → alexsavulov
Component: HTML Form Controls → Form Submission
(Assignee)

Updated

17 years ago
Summary: hidden form field transforms CR/LF to CR/CR/LF → hidden form field transforms CR/LF to CR/CR/LF[form sub]
(Assignee)

Comment 7

17 years ago
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.
Target Milestone: --- → mozilla1.2
(Assignee)

Comment 8

17 years ago
Created attachment 64013 [details]
the php script used in my test

this php script was served by a linux/apache/php server
(Assignee)

Comment 9

17 years ago
Created attachment 64014 [details]
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)
(Assignee)

Comment 10

17 years ago
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 = ........%#........%#........%#........
(Reporter)

Comment 11

17 years ago
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).
(Assignee)

Comment 14

17 years ago
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.

Updated

17 years ago
Priority: -- → P3
Why no activity on this bug ?
Is it going to be fixed in Mozilla 1.0 ?
-- peter
Blocks: 114997
*** 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....
Keywords: qawanted
QA Contact: madhur → ian
Marking invalid, since we are in fact doing exactly what we should be....
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.