65609 - [DOM] form elements inside of append subtrees aren't added to form

Status: VERIFIED FIXED

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

Description

[chris]

Adding form elements to an HTML page on the fly using Javascript
DOM methods produces a change in the page layout, but no change in the form
behavior. I.e., given an input element created as follows --

var in = document.createElement("select") ;
in.setAttribute("name", "input1") ;
// more initialization...
some_node.appendChild(in) ;

-- the element data does not appear as the result of a form
submission -- there is no parameter 'input1' available in the HTTP
request.

Mozilla 0.7/Win

Comment 1

[Fabian Guisset]

I think this is the same as bug 59533. However bug 59533 is only about text
inputs, so this is more general. Since jst assigned it to Eric Pollman, i'm
assigning this one to him too. 

Comment 2

[Keyser Sose]

Reporter do you have a testcase we use to verify this?

Comment 3

[chris]

Attachment: Demonstration of bug

Comment 4

[chris]

I've uploaded a test case. Creating it gave me some more insight into the bug.
Input elements DO appear in the posted form if they are appended directly to the
form element or one of its children. They do not appear if they are appended to
a new element that is subsequently appended to the form.

This works:
  theForm.appendChild(new_input) ;

And this works:
  var new_p = document.createElement('p') ;
  form_child.appendChild(new_p) ;
  new_p.appendChild(new_input) ;

However, this does not work:
  var new_p = document.createElement('p') ;
  new_p.appendChild(new_input) ;
  form_child.appendChild(new_p) ;

Both ways work in IE.

Comment 5

[Keyser Sose]

Confirmed
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001011704

Marking NEW.

Comment 6

[Eric Pollmann]

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

Comment 7

[Fabian Guisset]

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

Comment 8

[Eric Pollmann]

Thanks Fabian, this is indeed a dup!

*** This bug has been marked as a duplicate of 63954 ***

Comment 9

[Christopher L Conway]

Insofar as this bug may be a duplicate of bug 63954, that bug lacks the detail
provided above, specifically:

The form elements do not appear in the posted form ONLY when they are
"indirectly" appended to the form element, i.e., when they are appended to an
element that is then appended to the form. Any element appended directly to the
form WILL appear in the post.

Comment 10

[Eric Pollmann]

Oops, not really a dup - the other bug was a WFM, but this one really exists.
The problem is that when we add a form control to the content model, we search
for the form that contains it, which works in the second test case because we
are appending the control to a full document.  In the first case, however, when
we append the select, it searches for a containing form and doesn't find one,
then later when the subtree is added to the document, no search for a containing
form is performed.

Comment 11

[Eric Pollmann]

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

Comment 12

[Eric Pollmann]

Attachment: patch - set parent before setting document

Comment 13

[Eric Pollmann]

Turns out the search for a form parent *was* being performed in SetDocument, but
that was actually before the <td> was added to the content model (er, had it's
parent set).  This patch sets the <td>'s parent so that FindFormParent can
continue walking up the chain of content and locate the enclosing form.

Comment 14

[Prashant Desale]

QA contact Update

Comment 15

[Christopher L Conway]

With the patch uploaded, isn't it time to mark this resolved?

Comment 16

[Fabian Guisset]

Nope, it needs to be reviewed and checked-in before marking it fixed.

Comment 17

[Johnny Stenback (:jst)]

With a comment added in the source explainging why the SetParent() call is
needed I'll say sr=jst. Eric, given that you have a fix for this, could you land
this ASAP to give it as much milage as possible before the beta?

Comment 18

[Eric Pollmann]

Sure thing (oops, forgot about this little bug...)

Comment 19

[Eric Pollmann]

jst, when you get all rested up from the xpconnect dom conversion, I think I'll
need to bounce some questions off of you about this (before checking it in).  I
was trying to explain the change to Nisheeth for review today and I realized
that I don't fully understand all the implications.  :)  (Reviews are good, eh?)

Comment 20

[Eric Pollmann]

Attachment: alternate patch (aDeepSetDocument param added to relavent calls)

Comment 21

[Johnny Stenback (:jst)]

Remove the unrelated changes in nsHTMLContentSink and nsXMLContentSink
(scrollbar related) and I'm ok with this change, sr=jst, nice little one liner
turned into a quite large (but good) change :-)

Comment 22

[Eric Pollmann]

Fix checked in.

To verify:
 view the first attachment "Demonstration of bug"
 click on the button labeled Pre-append to TD (a new dropdown should appear)
 click on the button right below that labeled Post Form

Expected result:
 URL bar should read:
   http://bugzilla.mozilla.org/post-tester.jsp?select_box0=1&preTD0=1
 Before fix it would read:
   http://bugzilla.mozilla.org/post-tester.jsp?select_box0=1

Thanks!

Comment 23

[Prashant Desale]

Verified with 2001-05-22-04.