Closed Bug 273178 Opened 20 years ago Closed 11 years ago

DHTML added fields associated with incorrect form when multiple forms exist

Categories

(Firefox :: General, defect)

x86
Windows XP
defect
Not set
blocker

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: glenn, Unassigned)

Details

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I have a page with multiple (not nested, just multiple) forms.  The third form
has a nested Table that can be dynamically modified on the client; e.g., if they
click "Add", a new row is inserted; a new cell is inserted; and the new cell's
innerHTML is set to a valid HTML < input type = text > field.  

During submit, I noticed that I was not receiving any information back from the
fields that were dynamically created.  Thanks to the handy Web Developer
extension, I realized that despite the fact the table is a child of the third
form, the newly-generated fields were being associated with the FIRST form on
the page!

I also attempted to use "appendChild" instead of setting innerHTML, and I had
the same results.

Unfortunately, this issue will prevent me from saying that the web application I
am working on can be accessed from FireFox, which I was really hoping to say... 

My bug search only turned up one potential lead, and that was from someone who
had an improperly formatted page, so I'm afraid this bug discovery might be
"news" to the FireFox developers.  Please let me know, and thanks!

Reproducible: Always
Steps to Reproduce:
1.  Generate a page with multiple forms.
2.  Place a table in one of the forms - but NOT the first form.
3.  Add a new row to the table via addRow(-1).
4.  Add a new cell to the new row via addCell(-1).
5.  Set the innerHTML of the new cell to < input type= text id = FIELD name =
FIELD value = FIELDVAL > 
6.  Either use the FireFox WebDeveloper extension, or somehow submit the
appropriate form

Actual Results:  
You'll note that the new field is NOT associated with the form that the parent
table is associated with.  Instead, it is associated with the first form on the
page.

Expected Results:  
Dynamically created fields should belong to the same form that their parent
element belongs to.

Information above should be sufficient; please let me know if you need any
further details.

Please note that due to the fact that FORMS are so fundamental to web pages, and
that DHTML is the backbone of many pages as well, I consider this to be a major bug.
> ... a new cell is inserted; and the new cell's
> innerHTML is set to a valid HTML < input type = text > field.

innerHTML is a proprietary Microsoft DOM property.
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/innerhtml.asp

I'm not aware of the W3C way to do what you're doing, but presumably there is one.
This is one way to work around the absence of support for innerHTML and
innerText to add a text input inside a new row in a table in a form.
I guess it is supported. Maybe I should have tested that first before posting
the first attachment. (Whoops.)
The problem also occurs with a simple form swapping content using innerHTML or
replaceChild().   Form parameters are passed but values are NULL.  Same
parameters are non-null if data elements are not touched.

function swapRows( from_row, to_row ) {
        to_clone   = to_row.cloneNode( true );
        from_clone = from_row.cloneNode( true );
        to_row.parentNode.replaceChild( from_clone, to_row);
        from_row.parentNode.replaceChild( to_clone, from_row );
}

or 

tmp = rows[i].parentNode.innerHTML;
rows[i].parentNode.innerHTML = rows[i+1].parentNode.innerHTML;
rows[i+1].parentNode.innerHTML = tmp;


I also thought it was supported based on this link from mozilla
http://www.mozilla.org/docs/dom/domref/dom_el_ref8.html

 
This example --

> tmp = rows[i].parentNode.innerHTML;
> rows[i].parentNode.innerHTML = rows[i+1].parentNode.innerHTML;
> rows[i+1].parentNode.innerHTML = tmp;

-- should not work in IE, either. innerHTML is "read only" for the TR element in
MS-DHTML to protect the table structure. Does the code work in FF if you swap
every cell (TD element)?
I have ready access to an ASP server. The POSTs do include the proper fields
under these various scenarios, but the sequence changes when two rows are
swapped (the appear after any other rows in the table), which could break code
expected parameters in a particular order.
Attachment #167890 - Attachment is obsolete: true
I have verified this bug using both innerHTML and appendChild.  My page only has
one form on it and has the same problem.  If I attempt to append the child
elements to a table cell <td> or <div> it doesnt' work, the only way I could get
it to work was if I appendChild to the form object.  This really messes up the
flow of a dynamic form. 
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
> 
> I have a page with multiple (not nested, just multiple) forms.  The third form
> has a nested Table that can be dynamically modified on the client; e.g., if they
> click "Add", a new row is inserted; a new cell is inserted; and the new cell's
> innerHTML is set to a valid HTML < input type = text > field.  
> 
> During submit, I noticed that I was not receiving any information back from the
> fields that were dynamically created.  Thanks to the handy Web Developer
> extension, I realized that despite the fact the table is a child of the third
> form, the newly-generated fields were being associated with the FIRST form on
> the page!
> 
> I also attempted to use "appendChild" instead of setting innerHTML, and I had
> the same results.
> 
> Unfortunately, this issue will prevent me from saying that the web application I
> am working on can be accessed from FireFox, which I was really hoping to say... 
> 
> My bug search only turned up one potential lead, and that was from someone who
> had an improperly formatted page, so I'm afraid this bug discovery might be
> "news" to the FireFox developers.  Please let me know, and thanks!
> 
> Reproducible: Always
> Steps to Reproduce:
> 1.  Generate a page with multiple forms.
> 2.  Place a table in one of the forms - but NOT the first form.
> 3.  Add a new row to the table via addRow(-1).
> 4.  Add a new cell to the new row via addCell(-1).
> 5.  Set the innerHTML of the new cell to < input type= text id = FIELD name =
> FIELD value = FIELDVAL > 
> 6.  Either use the FireFox WebDeveloper extension, or somehow submit the
> appropriate form
> 
> Actual Results:  
> You'll note that the new field is NOT associated with the form that the parent
> table is associated with.  Instead, it is associated with the first form on the
> page.
> 
> Expected Results:  
> Dynamically created fields should belong to the same form that their parent
> element belongs to.
> 
> Information above should be sufficient; please let me know if you need any
> further details.
> 
> Please note that due to the fact that FORMS are so fundamental to web pages, and
> that DHTML is the backbone of many pages as well, I consider this to be a
major bug.

--------------------------------------------------------------------------------
I've had a similar problem using appendChild and I've found out the following:

consider the following html code

///////////////

<table>
   <form action='' method='GET'>
     <tr>
         <td>       
            <table id='writeroot'>  
              <tr id='template'> 
                <td> <--! stuff here --> </td>
              </tr>
            </table>
            <br><input type='submit' name='submit' value='SUBMIT'>
         </td>
     </tr>      
  </form>
</table>    


//////////

suppose the somewhere else in the html page there's a button. If you click on it
  a function is called that creates a copy of
document.getElementById("template") and appends it to the tbody child of the
table with id='writeroot'.

when you append new form fields and submit (you can see the vars and value in
the url address bar) the dynamically added fields are NOT submitted.

however !!!! if you change the position of the <form> so instead of before the
<tr> tag the form tag is before the table tag!!!
<form>
<table>
  <tr>
    <td>
      ...
   </td>
 </tr>
</table>
</form>

everything works !!!!!!!!!!!11

if you want to ... email me for html code of my test pages!!!

BTW my advice is to use DOM's childAppend instead of innerHTML
Attachment #189409 - Attachment description: see my comment (this is the html code I'm talking about) → see my comment https://bugzilla.mozilla.org/show_bug.cgi?id=273178#c8
I had the same problem, and it was fixed by placing the form-tag outside the
table-tag.

However doing so is causing trouble with other forms on the page that is
supposed to be in the same table.

Sincerely Tomas Wallentinus
i have the same error. Tried with changing the position of <form> tags, and it didn't help. I have many tables in my form and think it's the problem. When I do the appendChild to the form object, dynamically added field doesn't show on the form, but it's value is passed thru POST. When I append this to any other object (div, li, etc) the form is shown but the POST value is not passed on.
it's the first time i had to make "ie only" tag
(In reply to comment #11)
> i have the same error. Tried with changing the position of <form> tags, and it
> didn't help. I have many tables in my form and think it's the problem. When I
> do the appendChild to the form object, dynamically added field doesn't show on
> the form, but it's value is passed thru POST. When I append this to any other
> object (div, li, etc) the form is shown but the POST value is not passed on.
> it's the first time i had to make "ie only" tag
Your form sounds quite complicated with internal tables, divs, and lists. I suggest visiting the following board for some assistance in sorting out what is happening: Mozillazine Forums -> Web Development / Standards Evangelism (http://forums.mozillazine.org/viewforum.php?f=25)
Assignee: bross2 → nobody
The test cases seem to work perfectly here. Perhaps it's time to resolve this bug.
Does https://bugzilla.mozilla.org/attachment.cgi?id=189409 follow HTML spec? The nested order is: <table><form><tr>

Usually <table> should be directly followed by <tr>
If you try <table><p><tr> you'll see some awkward results.
WFM with 21.0a1.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: