Closed Bug 63954 Opened 24 years ago Closed 20 years ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: marc, Assigned: alexsavulov)

Details

(Keywords: dom1)

Attachments

(4 files)

example for form bug
901 bytes, text/html
Details
dynamic form example - name attribute needed to submit
931 bytes, text/html
Details
Re-worked test case to illustrate data loss
784 bytes, text/html
Details
Sorry - typo in original upload of this test case
793 bytes, text/html
Details 
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>
Attached file example for form bug — 

    
    

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

    
    

    
  
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

    
    

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

    
    

    
  
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!

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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

    
    

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

    
    

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

    
    

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

    
    

    
  
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

    
    

    
  
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>



    
    

    
  
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.

    
    

    
  
QA contact Update
QA Contact: janc → desale

    
    

    
  
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
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
does not work for the testcase given above...
dynamic form variables are not posted to form ...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
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.

    
    

    
  
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
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
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

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

    
  
Target Milestone: mozilla0.9 → mozilla0.9.6

    
    

    
  
retargeting
Target Milestone: mozilla0.9.6 → mozilla0.9.7

    
    

    
  
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: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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"




    
    

    
  
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.


    
    

    
  
reopening based on above comments
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
retargeting
Target Milestone: mozilla0.9.7 → Future

    
  
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.

    
    

    
  
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
Closed: 23 years ago → 20 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: