dynamic form data not attached to form / not sent[form sub]

RESOLVED WORKSFORME

Status

()

P2
critical
RESOLVED WORKSFORME
18 years ago
10 years ago

People

(Reporter: marc, Assigned: alexsavulov)

Tracking

({dom1})

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

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

18 years ago
Created attachment 21445 [details]
example for form bug

Comment 2

18 years ago
I think this is the same as bug 58089. Reporter, can you confirm?
Thanks,
Fabian.

Comment 3

18 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.
Reassigning to pollmann who normally works on form submission.
Assignee: jst → pollmann

Comment 5

18 years ago
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

18 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

18 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

18 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

18 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

18 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).
Keywords: dom1
Component: DOM Level 1 → DOM HTML

Comment 11

18 years ago
Per talk with jst, commenting in this bug:
This is the same as bug 65609 and bug 59533.

Comment 12

18 years ago
*** Bug 65609 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
*** Bug 59533 has been marked as a duplicate of this bug. ***

Comment 14

18 years ago
Created attachment 26561 [details]
dynamic form example - name attribute needed to submit

Comment 15

18 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
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 16

18 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

18 years ago
Created attachment 26571 [details]
Re-worked test case to illustrate data loss

Comment 18

18 years ago
Created attachment 26572 [details]
Sorry - typo in original upload of this test case

Comment 19

18 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 20

18 years ago
QA contact Update
QA Contact: janc → desale

Comment 21

18 years ago
Jim Kilmer provided new testcase now that does not work. Reopening bug.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Please open a new bug on that and attach the testcase.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 23

18 years ago
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala

Comment 24

18 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

18 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

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

Resolving bug as fixed.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED

Comment 28

17 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 → ---
Bulk reassigning Eric Pollmann's remaining form submission bugs to Alex.
Assignee: pollmann → alexsavulov
Status: REOPENED → NEW
(Assignee)

Updated

17 years ago
Summary: dynamic form data not attached to form / not sent → dynamic form data not attached to form / not sent[form sub]

Updated

17 years ago
Target Milestone: mozilla0.9 → mozilla0.9.6
(Assignee)

Comment 30

17 years ago
retargeting
Target Milestone: mozilla0.9.6 → mozilla0.9.7
(Assignee)

Comment 31

17 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
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 32

17 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

17 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
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 34

17 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

17 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

17 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

17 years ago
reopening based on above comments
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 38

17 years ago
retargeting
Target Milestone: mozilla0.9.7 → Future

Updated

17 years ago
Priority: -- → P2
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

14 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.
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
Last Resolved: 17 years ago14 years ago
Resolution: --- → WORKSFORME

Updated

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