Closed
Bug 273178
Opened 20 years ago
Closed 12 years ago
DHTML added fields associated with incorrect form when multiple forms exist
Categories
(Firefox :: General, defect)
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.)
Comment 4•20 years ago
|
||
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
Comment 7•20 years ago
|
||
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.
Comment 8•19 years ago
|
||
(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
Comment 9•19 years ago
|
||
Updated•19 years ago
|
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
Comment 10•19 years ago
|
||
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
Comment 11•19 years ago
|
||
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
Comment 12•19 years ago
|
||
(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)
Updated•18 years ago
|
Assignee: bross2 → nobody
Comment 13•15 years ago
|
||
The test cases seem to work perfectly here. Perhaps it's time to resolve this bug.
Comment 14•14 years ago
|
||
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.
Comment 15•12 years ago
|
||
WFM with 21.0a1.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•