Closed Bug 84185 Opened 23 years ago Closed 23 years ago

Form fields created in DOM are not correctly attached to surrounding forms.

Categories

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

defect
Not set
critical

Tracking

()

VERIFIED INVALID

People

(Reporter: jkilmer, Assigned: jst)

Details

Attachments

(1 file)

This bug has been created by request of Johnny Stenback as a new (and 
hopefully better defined) instance of Bug 63954.

When form fields are created by a script embedded in a page, if those fields are 
not explicitly attached to the form by use of FORMNAME.appendChild(), they 
appear correctly, but do not have their data sent back on form submit.

In other words, if you define a form with <FORM></FORM>, and then, inside, 
create fields in the DOM and append them to a table cell, a div, or the page 
body itself, the field is not submitted along with fields created in HTML-esque 
<INPUT...> format.

This is flagged as critical because it is causing data loss!  The fields 
appear, but their data is vaporized upon form submit.  

I will attach a test case "confirmed" not to work as soon as this is submitted.
Are you sure this SHOULD work?  It seems to me that the resulting DOM tree would
be something like:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML>
<BODY>
<H2>Dynamic Form Test Case</H2>
When you submit this form, the script called will display all submitted fields
and their values.<BR>
<FORM NAME="test" ID="tester" ACTION="..." METHOD="POST">
<script>...</script>
This one works:<INPUT TYPE="text" NAME="testtext" VALUE="blah..."><BR>
<INPUT TYPE="submit" VALUE="Go!">
</FORM>
...
<INPUT size="25" name="dynatext" /></body>

which I would not expect to submit the dynatext field anyway since it is not a
descendant of the <form> element.

Try document.forms[0].appendChild(newInput) and it'll work, dynamically created
form controls must be decendants of the form to submit and to be part of the
form. Marking INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Before we leave this topic behind, however, this is still indicative of problem 
in the DOM implementation.  If hierarchical inheritance is not honored in 
Mozilla, then this should generate an error -- specifically 
HIERARCHY_REQUEST_ERR -- when an operation of this sort is requested, and thus 
not render the field, specifically because, as the spec states, "data is lost."  
Mozilla renders it anyhow.  Check the DOM spec on this at 
http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-one-core.html#ID-1718918
7

In any event, both the DOM spec and the DTD (transitional and strict) state that 
input fields can be attached to parents of type TD, DIV, and many others.  
Transitional even allows them to be attached to BODY, which is what my test case 
illustrated.  

Jason, regarding your observation, you are correct, insofar as recent builds of 
Mozilla do render it that way.  Previously (prior to about May 15... I don't 
know the exact build that changed it), the field rendered in-line in the 
appropriate place, preserving the rendering hierarchy even though the end 
behaviour was still the same.

For an example of a truly pathological case where this can occur, visit 
http://gallery.theopalgroup.com/DOMsheet/table.html  Even though there's no 
submit button to send the fields anywhere, rest assured, Mozilla would/does not 
submit them.  According to the verifiers and reviewers who looked at our 
implementation, its behavior is compliant with the spec, and sadly, IE does do 
it properly.

I'm not saying Mozilla should support this, but if it's not, it should 
definitively NOT support it, and not render the field at all, throwing an 
exception in the process...
v
Status: RESOLVED → VERIFIED
Jim-- I think there are multiple issues being discussed here.  Let's break them
down; this bug may need to be reopened.

The testcase you attached is one issue, which I believe Moz does correctly, and
is not actually creating data loss.  When you use the DOM to create elements,
the behavior of those elements depends on their position in the content tree
(not the position of their creator script).  So your testcase appends an <input>
element to the <body> element, but OUTSIDE of the <form> element.  Imagine then
a static HTML document with a structure exactly like your resulting content
tree.  Such a document would submit the fields inside the <form> element but not
the one outside of it.  There is no data loss because according to the tree
structure that field's data was not part of the form to submit in the first place.

However, you also mentioned that if you append an <input> element to a
_descendant_ of the <form> then that field will not be submitted either.  So if
a script uses the DOM to create a tree like:
<form action="...">
  <div>
    <span><input ... /></span>
  </div>
</form>
by creating and appending the <input> element via the DOM, then that field will
not submit either.  In this case, we do get data loss because a you would expect
a static document with that structure to submit the field's data.  Your example
at gallery.theopalgroup.com should therefore submit the dynamic fields because
they are descendants of the form even though they're children of table cells.

This is all dependent upon the assumption that this actually doesn't work in
Mozilla, which I haven't tested.  If you could work up a testcase and confirm
that fields appended to descendants of the form are not submitted, please attach
it to this bug and reopen it.
Component: DOM: HTML → DOM: Core & HTML
QA Contact: desale → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: