255431 - inserting table row with DOM insertBefore fails to register form components in that row with the form around it

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect)

Description

[Stephen Haney]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

This bug is on the company intranet so I can't link you in.  Basically what I'm
doing is dynamically adding new table rows to my table using DOM .appendChild
and .insertBefore.  The problem is, inside these table cells are form components
(file inputs, specifically).  They don't seem to be registering as inside the
form, though the form tags surround the area they're being inserted into.

In IE, this seems to register correctly.  Probably a difference in the way
dynamically added content is parsed.   The information that you type into these
forms inside the dynamically added cells isn't passed along with the rest of the
form.

I've tried adding the file inputs as child nodes of my form object, but this
doesn't seem to help.

Reproducible: Always
Steps to Reproduce:
1. Write a quick DOM script to insertBefore a table row and cell into a previous
table body
2. Put form tags around the spot that these cells will be inserted

Actual Results:  
The information inside these dynamically added inputs won't be passed along with
the rest of your form.

Expected Results:  
If it could match IE's ability to automatically pass any dynamically added
inputs that are inserted inbetween form tags, that would be optimal.

Comment 1

[Martijn Wargers (dead)]

Colud you attach a small testcase, which shows the bug? Thanks.

Comment 2

[Stephen Haney]

Attachment: Quick demo I threw together to display the bug

Since I'm not sure if you guys have the capacity to run ASP pages, I uploaded
this file to our servers too.  You can get to it at: 
http://www.avalonnaturalproducts.com/marketform/admin.asp

This page was created by weeding out all the functionality of the actual page
I'm working on until all that was left was the DOM form part.  Sorry if this
makes some of the code confusing or seemingly out of order.

To operate this page, click the little plus sign next to the word
"attachments".	Another field for an attachment should appear.	Select two
attachments, one in each box, and hit submit.

The refresh simply displays what fields were passed to it.  In IE, you get all
of the field's values.	In Firefox or mozilla you only get the value from the
very first field - the one that is hard coded in.  The dynamically added file
inputs don't seem to register as being part of the form.

Hope this helps.

Comment 3

[Stephen Haney]

Comment on attachment 156046 [details]
Quick demo I threw together to display the bug

note - the form action of this attachment doesn't work properly in your
attachment environment.  Just use the link.

Comment 4

[Martijn Wargers (dead)]

Attachment: testcase

Well, you put your begin <form> tag and end </form> tag inside table cells.
This can't work well the way you do, because the begin and end tag are in a
different table cell. 
Mozilla tries to make a document tree of the document and closes the form
element when the table cell is closed. The </form> tag you put there is
ignored. 
Apparently IE makes a different document tree, but that doesn't make this
Mozilla's fault. 

What you should do is, put the <form> tags around the entire table. 
That way it works as you can see in the example I attached here. I hope this
helps.

I see a crash occuring, by the way, when trying to removing an input file
element (by clicking the '-' link). But that's a different bug. Maybe it has
already been filed, otherwise that one should be filed in a separate bug.

Comment 5

[Martijn Wargers (dead)]

I've submitted bug 255845 for the crasher.

Comment 6

[carglue a t ya hoo do tcom]

Copied from bug #260967...

The following snippet breaks the DOM tree relationship between the FORM 
element and its INPUT children.  Yet, it works fine if you remove the TABLE 
tagset immediately surrounding the FORM tagset and inner structure.

<HTML>
<HEAD></HEAD>
<BODY>
  <TABLE>
    <TR>
      <TD>
        <TABLE>
          <FORM name="loginForm" action="/login/doLogin.cgi" method="post">
            <INPUT name=USER/>
            <INPUT name=PASSWORD type=password/> 
          </FORM>
        </TABLE>
      </TD>
    </TR>
  </TABLE>				
</BODY></HTML>

Saying that "its invalid HTML syntax" is not the solution to this issue 
because HTML parsing is supposed to be forgiving.  The FORM tags clearly 
surround the INPUT tags, and so that relationship should be honored in the 
DOM.  But DOM tree navigation breaks in this scenario.  Also, its not always 
fixable in the HTML because you might be pointing to someone else's website 
when walking the DOM tree (perhaps inside of a firefox extension), so you 
can't always control the HTML your looking at.  

IE allows this syntax.  Its clearly a bug.  And unfortunately, now I have to 
spend the next 2 hours trying to hard-code a special case workaround for this 
bug in my firefox extension so I can still walk up the DOM tree even if 
someone accidentally sticks a TABLE tag around a FORM tag and breaks the DOM 
navigation links.
 

Comment 7

[Martijn Wargers (dead)]

David, please don't copy comments from the one bug to the other. Comment 6 may
seem the same, but is unrelated to this.

Anyway, moving to parser, although I doubt there is something that can be done
about this specific case.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yeah, this is wontfix.  There's no way to handle this gracefully in the face of
DOM mutations.