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)
Core
DOM: Core & HTML
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.
|
Reporter | |
Comment 1•23 years ago
|
||
|
||
Comment 2•23 years ago
|
||
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.
|
Assignee | |
Comment 3•23 years ago
|
||
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
|
|
Reporter | |
Comment 4•23 years ago
|
||
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...
|
|
||
Comment 6•23 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•