Closed Bug 34987 Opened 25 years ago Closed 24 years ago

Changing the value of a 'hidden' input item doesn't work

Categories

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

x86
Windows 2000
defect

Tracking

()

VERIFIED DUPLICATE of bug 27006

People

(Reporter: erick_jensen, Assigned: pollmann)

References

()

Details

(Whiteboard: [nsbeta2+][WORKSFORME, waiting for input])

I have a shopping cart page that uses JavaScript and cookies extensively. In the HTML of the page I have a 'hidden' input tag that I set to a null string initially. When the user clicks on one of two submit links, I use JavaScript to call a function. In this function I have some logic to determine what goes into this 'hidden' tag and gets passed along to my CGI script. Then I call the form.submit() function to call the script. Somehow the changes I make to the 'hidden' tag are not getting set, it only passes along the null string. This works perfectly in Netscape 4.x and IE4/5.
Reassign from Rhino (not used in mozilla browser) to DOM.
Assignee: norris → jst
Component: Core → DOM Level 0
Product: Rhino → Browser
QA Contact: cbegle → desale
reassign to owner of component
I tried this with following testcase and it works fine for me. <html> <head> <title></title> <script language="javascript"> <!-- function testit(text) { if (document.workform.hid.value=='old value'){ document.workform.hid.value='new value'} else if (document.workform.hid.value=='new value'){ document.workform.hid.value='old value'} else{ document.workform.hid.value='another value'} alert("Hidden Value= " + document.workform.hid.value); } // --> </script> </head><body> <FORM NAME="workform"> <INPUT TYPE="hidden" NAME="hid" VALUE="old value"> <INPUT TYPE="button" NAME="but" VALUE="Change Hidden Value" onClick="testit(this.form.hid.value);"> </FORM> </body> </html> For me its working fine.
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Nominating nsbeta2. We have to start drawing a line on DOM0 backward compatibility; these bugs are supposed to be a high priority for nsbeta2 per the beta2 criteria.
Keywords: nsbeta2
This is needed for beta2; giving PDT approval.
Whiteboard: [nsbeta2+]
Erick Jensen, could you please supply some more info here, is the code you use different in some way from the code desale tested with? I'm currently unable to use the site because of the javascript: url problems in mozilla, but the sample that desale showd above works just fine for me too.
Whiteboard: [nsbeta2+] → [nsbeta2+][WORKSFORME, waiting for input]
I've discovered that the problem isn't actually with changing hidden input tags, it's with transmitting form data via the HTTP header to a CGI script. It doesn't seem to be sending it accross. I wrote a simple HTML form with a CGI/Perl script that displays the fields entered. They show up blank in N6, but show up fine in N4 and IE5. This may actually be a bug that has already been reported, I didn't check. In any case it's pretty severe. Try this link to see what I mean: http://www.llmedico.com/ejensen/test.html. I am also sending you (jst@netscape.com) the two source files.
CCing myself and Eric Pollmann.
jst, this sounds like form submission to me. I'll take a look at this one. :) (Feel free to take it back if you have or are working on a solutions!)
Assignee: jst → pollmann
Status: ASSIGNED → NEW
Component: DOM Level 0 → Form Submission
Interestingly, if I make the action of the form http://pollmann.net/echo.cgi it seems to have no problems with the post - wonder if this is a server side issue?
Status: NEW → ASSIGNED
Ah, good old bug 27006. The post data is getting sent correctly the first time, the server is responding with a document with a <META> tag that contains a charset. This causes the form to be posted again, this time (due to the bug) without the post data! *** This bug has been marked as a duplicate of 27006 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified Duplicate.
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.