Closed
Bug 63954
Opened 24 years ago
Closed 21 years ago
dynamic form data not attached to form / not sent[form sub]
Categories
(Core :: DOM: Core & HTML, defect, P2)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: marc, Assigned: alexsavulov)
Details
(Keywords: dom1)
Attachments
(4 files)
When I dynamically create a form, the input fields and textarea's that
are created with it are not transmitted when the form is submitted:
Here is a short example:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>mozilla form bug</title>
<script>
function createForm() {
eltForm = document.createElement("form");
eltForm.method = "get";
eltForm.action = "http://localhost/cgi-bin/printenv";
eltTextArea = document.createElement("textarea");
eltTextArea.defaultValue = "some text";
eltForm.appendChild(eltTextArea);
eltForm.appendChild(document.createElement("br"));
eltSubmit = document.createElement("input");
eltSubmit.type = "submit";
eltSubmit.value = " Ok ";
eltForm.appendChild(eltSubmit);
document.getElementsByTagName("body").item(0).appendChild(eltForm);
}
</script>
</head>
<body>
<h1>mozilla form bug</h1>
<input type="button" value="Create form" onClick="createForm()">
</body>
</html>
|
Reporter | |
Comment 1•24 years ago
|
||
|
||
Comment 2•24 years ago
|
||
I think this is the same as bug 58089. Reporter, can you confirm?
Thanks,
Fabian.
|
|
||
Comment 3•24 years ago
|
||
From the reporter :
"This is not the same as bug 58089.
The bug I'm reporting is that when I create a form (you can try the
example I included) that the formdata doesn't get sent when you
GET or POST the form. The REQUEST_STRING (in case of GET) is
completely empty. I also tried cloning a form which had all
fields prefilled, but that turned up empty as well.
So to be precise, not only the formdata doesn't get sent, but
neither are the input variables, it is as if you submit an
empty form, i.e.:
<form action="..." method="get">
<input type="submit" value="submit">
</form>
"
Hope this helps.
|
||
Comment 4•24 years ago
|
||
Reassigning to pollmann who normally works on form submission.
Assignee: jst → pollmann
|
||
Comment 6•24 years ago
|
||
Bug confirmed on platforms/OSs other than FreeBSD (Linux, Win32) and likely
exists on all platforms. This bug should be reclassed to severity CRITICAL!!
Data loss is occurring as a result of it. Platform/OS/Severity should be
updated ASAP.
Any form fields created in the DOM are not successful. Correct behavior of the
DOM is experienced in IE5 and IE5.5, but as of the latest nightly build, both
Mozilla and NS6 contain this bug.
It only affect dynamic fields, not forms overall. For instance:
<FORM NAME="test" ID="tester" ACTION="/cgi-bin/echovars" METHOD="POST">
<script>
form = document.getElementById("tester")
tx = document.createElement("INPUT")
tx.size = 25
tx.name = "dynatext"
tx.id = "dynatext"
form.appendChild(tx)
</script>
<INPUT TYPE="hidden" NAME="testtext" VALUE="blah...">
<INPUT TYPE="submit" VALUE="Go!">
</FORM>
"testtext" will be received by the server. "dynatext" will not!
|
||
Comment 7•24 years ago
|
||
CC'ing possibly interested parties. Ideas on how to address this problem?
Johnny, is this a dup?
Severity: normal → critical
Status: NEW → ASSIGNED
OS: FreeBSD → All
Hardware: Other → All
Summary: dynamic form data doesn't get send → dynamic form data not attached to form / not sent
Target Milestone: --- → mozilla0.9
|
||
Comment 8•24 years ago
|
||
Exactly the same thing happens if the form is generated by a CGI script rather
than JavaScript -- whatever was generated dynamically, does not get sent to
the server when the form is submitted.
|
||
Comment 9•24 years ago
|
||
The last comment is clearly not the case if a CGI emits raw HTML with form elements. If it were, then virtually every CGI form would be broken.
|
|
||
Comment 10•24 years ago
|
||
Upon further investigation, what I see is a different issue. The parameters of a
form (either generated by a CGI script or static, doesn't actually matter) don't
get transmitted when the FORM tag has a TARGET="_blank" attribute. E.g., with
<FORM NAME=test ACTION=/cgi-bin/test.cgi METHOD=POST>
<INPUT TYPE=text NAME=message SIZE=15>
<INPUT TYPE=submit>
</FORM>
test.cgi does get the value of 'message', but with
<FORM NAME=test ACTION=/cgi-bin/test.cgi TARGET="_blank" METHOD=POST>
<INPUT TYPE=text NAME=message SIZE=15>
<INPUT TYPE=submit>
it does not.
I guess this should be made into a separate bug (if such does not exist). Sorry
about the confusion (I noticed it with dynamically generated forms and did not
see the role of TARGET in the first place).
|
||
Updated•24 years ago
|
Component: DOM Level 1 → DOM HTML
|
|
||
Comment 11•24 years ago
|
||
|
|
||
Comment 12•24 years ago
|
||
*** Bug 65609 has been marked as a duplicate of this bug. ***
|
|
||
Comment 13•24 years ago
|
||
*** Bug 59533 has been marked as a duplicate of this bug. ***
|
|
||
Comment 14•24 years ago
|
||
|
|
||
Comment 15•24 years ago
|
||
The last example works in N6 and IE5. The original test case works in neither.
The only difference between them is that in the last example, I set a name
attribute on the form element. This is required for the element to be
"successful" and have it's value submitted to the server, per the HTML spec.
I'll test the bugs that I just marked as DUPS to make sure they are okay too.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
|
|
||
Comment 16•24 years ago
|
||
Jim, your test case will not work as an HTML fragment because the form is not
added to the document's content model until after the script tries to get it.
However, if you enclose it in a valid HTML document like this, it will work fine:
<html>
<body>
<FORM NAME="test" ID="tester" ACTION="/cgi-bin/echovars" METHOD="POST">
<script>
form = document.getElementById("tester")
tx = document.createElement("INPUT")
tx.size = 25
tx.name = "dynatext"
tx.id = "dynatext"
form.appendChild(tx)
</script>
<INPUT TYPE="hidden" NAME="testtext" VALUE="blah...">
<INPUT TYPE="submit" VALUE="Go!">
</FORM>
</body>
</html>
|
|
||
Comment 17•24 years ago
|
||
|
|
||
Comment 18•24 years ago
|
||
|
|
||
Comment 19•24 years ago
|
||
Why my original test case works, I can't say. Best guess is that perhaps
whatever is breaking _stays_ breaking, and I'm not sure I ever ran the test case
on a fresh instance of Mozilla as opposed to one that had already yakked on my
production system where the bug originally occurred.
Check out the new test case (sorry for the first typo'd upload).
The problem seems to be occurring not on a form that is dynamically created in
general, but when the input fields are appendChild()'d on to something that is
not a form element. In the test case, the element was simply appended to the
body. In other words, they are created sequentially within the appropriate form
tags, but the DOM fails to bind them to the form if they are not explicitly
appendChild()'d onto the form element itself.
This becomes more relevant when applied to something like a DIV or a TABLE. The
blanket FORM element covers the whole page, and when a script creates a form
field and then appends it to a DIV or a TD, or whatever, the field is
appropriately displayed, but its data does not get sent upon a form submit.
My new test case will illustrate this, but I can provide examples of this
occurring in a DIV or TABLE as well, where your working test case will fail, if
any other problems or WORKSFORME's are encountered.
|
||
Comment 21•24 years ago
|
||
Jim Kilmer provided new testcase now that does not work. Reopening bug.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
|
|
||
Comment 22•24 years ago
|
||
Please open a new bug on that and attach the testcase.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
|
||
Comment 24•24 years ago
|
||
does not work for the testcase given above...
dynamic form variables are not posted to form ...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
|
|
||
Comment 25•24 years ago
|
||
Please be aware that this was already re-opened as a new bug, Bug 84185. That
bug has also been closed, but for slightly different reasons, and discussion is
still somewhat ongoing.
This bug was appropriately closed.
|
||
Comment 26•24 years ago
|
||
I think, the bug should be closed.
The reopening was invalid for me.
Cause the testcase is false. A input element ouside of the form element
shouldn't send his data. So it's no data lose for me.
You also can't say that input elements outside of a form element should send his
data too. The proplem would be:
<pre>
<form>
<input name="abc" value="mozilla">
</form>
<input name="abc" value="mozilla2">
</pre>
|
||
Comment 27•24 years ago
|
||
Resolving bug as fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
|
|
||
Comment 28•24 years ago
|
||
reopening bug does not send dynamic form data.
testcase to demonstrate the problem.
http://kajal.mcom.com/dyna.html
sorry if u cannot access the machine, please load the testcase in your webserver
to test.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
|
|
||
Comment 29•24 years ago
|
||
Bulk reassigning Eric Pollmann's remaining form submission bugs to Alex.
Assignee: pollmann → alexsavulov
Status: REOPENED → NEW
|
Assignee | |
Updated•24 years ago
|
Summary: dynamic form data not attached to form / not sent → dynamic form data not attached to form / not sent[form sub]
|
||
Updated•23 years ago
|
Target Milestone: mozilla0.9 → mozilla0.9.6
|
|
Assignee | |
Comment 31•23 years ago
|
||
The page attached at the end of this comment works perfect in all three cases.
If you're behind the firewall you can try:
http://206.222.241.94/jsform.html
(tested with mozilla tree pull from 11.5.2001/noon)
stummala:
Could you please check your test environment setup?
I miss some [;] (semicolon) in your script...
MARKED AS FIXED
<html>
<head>
<title>JAVASCRIPT FORM</title>
<script language="javascript">
function doTxtInput(formid) {
var thefrm = document.getElementById(formid);
tx = document.createElement("input");
tx.type = "text";
tx.value = "Javascript text input";
tx.name = "jsText";
thefrm.appendChild(tx);
}
function doAGetForm() {
document.write("HERE FOLLOWS A FORM GENERATED BY JAVASCRIPT:<br>");
frm = document.createElement("form");
frm.method = "get";
frm.action = "jsform.php";
txx = document.createElement("input");
txx.type = "text";
txx.value = "Javascript text input in a javascript GET form";
txx.name = "jsGetText";
frm.appendChild(txx);
sbm = document.createElement("input");
sbm.type = "submit";
sbm.value = "javascript GET form";
frm.appendChild(sbm);
document.getElementsByTagName("body").item(0).appendChild(frm);
}
function doAPostForm() {
document.write("HERE FOLLOWS A POST FORM GENERATED BY JAVASCRIPT:<br>");
frm = document.createElement("form");
frm.method = "post";
frm.action = "jsform.php";
txx = document.createElement("input");
txx.type = "text";
txx.value = "Javascript text input in a javascript POST form";
txx.name = "jsPostText";
frm.appendChild(txx);
sbm = document.createElement("input");
sbm.type = "submit";
sbm.value = "javascript POST form";
frm.appendChild(sbm);
document.getElementsByTagName("body").item(0).appendChild(frm);
}
</script>
</head>
<body>
<script language="javascript">
doAGetForm();
</script>
<hr>
<script language="javascript">
doAPostForm();
</script>
<hr>
HERE FOLLOWS A REGULAR FORM WITH A JAVASCRIPT GENERATED INPUT:<br>
<form id="thisfrm" method="post" action="jsform.php" name="theform">
<br>
the following input is created with javascript
<br>
<script language="javascript">
doTxtInput("thisfrm");
</script>
<br>
<input type="text" value="HTML text input" name="htmltext">
<br>
<input type="submit" value="post"> </form>
<br><br>
<br><br>
<div align="center">
<a href="index.html">_ HOME _<a>
</div>
<br><br>
<br><br>
</body>
</html>
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
|
|
||
Comment 32•23 years ago
|
||
testcase provided you added do work on linux and windows, however the testcase
which i added does not work. Alex, i did not see any semicolon missing.
Reopening the bug, i see the problem more as an inline javascript.
http://bugzilla.mozilla.org/show_bug.cgi?id=63954#c28
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
|
|
Assignee | |
Comment 33•23 years ago
|
||
please check your server environment. i tested the script
http://kajal.mcom.com/dyna.html
against my php server and is working.
(set action="http://206.222.241.94/return.php")
Try the server script "echovars" and the test case mentiooned above with IE 6.0,
you'll see it does not work either.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
|
|
||
Comment 34•23 years ago
|
||
this is what i have on serverside ..
#!/usr/bin/perl
use CGI;
$query = new CGI;
$var1 = $query->param('dynatext');
$var2 = $query->param('testtext');
print "Content-type: text/html\n\n";
print "<p>$var1</p>";
print "<p>$var2---</p>";
I did not see a problem with this script, i don't know where this is failing.
Per your comment i checked on IE5.x, it is working on IE5.x
|
|
Assignee | |
Comment 35•23 years ago
|
||
A BIG HMMMMM.....
i used IE 6.0 to test and is failing.
can you access the php server mentioned above? try with
action="http://206.222.241.94/return.php"
|
|
||
Comment 36•23 years ago
|
||
The page reads,
Values submitted via POST method:
and there is no text after the colon. I think it is failing. The build i am
using is Gecko/20011207. If you agree with me i will reopen the bug.
|
|
||
Comment 37•23 years ago
|
||
reopening based on above comments
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
|
|
||
Updated•23 years ago
|
Priority: -- → P2
|
||
Comment 39•21 years ago
|
||
This bug has not been touched for nearly 2 years. In most cases, that
means it has "slipped through the net".
Could someone please take a moment to add a comment to the bug with current
status, and/or close it.
|
||
Comment 40•21 years ago
|
||
Here is some additional behavior that I think relates to this
bug [from a post I sent to netscape.public.mozilla.dom]:
f = document.createElement('form');
ip1 = document.createElement('input'); ip1.type = 'text';
f.appendChild(ip1);
alert("1. Elements length=" + f.elements.length);
document.body.appendChild(f);
alert("2. Elements length=" + f.elements.length);
ip2 = document.createElement('input'); ip2.type = 'text';
f.appendChild(ip2);
alert("3. Elements length=" + f.elements.length);
document.body.removeChild(f);
alert("4. Elements length=" + f.elements.length);
f.removeChild(ip1);
alert("5. Elements length=" + f.elements.length);
In IE (and Opera), the alerts read:
1. Elements length=1
2. Elements length=1
3. Elements length=2
4. Elements length=2
5. Elements length=1
In Mozilla, they read:
1. Elements length=0
2. Elements length=1
3. Elements length=2
4. Elements length=2
5. Elements length=1
Apparently, the form's elements collection is not updated as elements are
added to the form, unless the form is part of a/the document. However, the
collection *is updated* as elements are removed, whether or not the form is
part of the document.
In n.p.m.d, bzbarsky replied:
Yep. That's exactly what we do, and it's a bug.
If you can't find it in bugzilla, file it and cc "bzbarsky". Maybe
mention that the problem is in nsGenericHTMLFormElement::SetParent (the
"non-null parent" branch does an IsInDocument() check that it really
doesn't need to do).
Done.
|
||
Comment 41•21 years ago
|
||
Howard, could you please file a separate bug on the problem you mention? This
bug as originally filed worksforme and the "re-worked testcase" is invalid.
What you're seeing is a different (and valid, and reproducible) bug.
Marking this bug worksforme yet again. Please do not reopen and mutate it
anymore; file new bugs on problems that arise.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → WORKSFORME
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in
before you can comment on or make changes to this bug.
Description
•