I have a form that creates new form elements by clicking a button. These form elements are not recognized when the form is submitted UNLESS they are top-level. They are embedded in a DIV and thus not recognized. If the DIV was not there in the insertion string, this example works. Please refer to the coming attachment, and view the queryString that it generates after adding 3 or 4 INPUTs. The new elements are named mine1, mine2, mine3... The current INPUT is named mine1.
See bug 35484. I believe these are the exact same problem.
Added a URL that can show you without a page not displayable error. Everything is the same as the attachment except it submits to a page that shows form values. This is the last real _blocker_ for my web applications to run with Mozilla! This makes me wonder what's going on with creating a contextual fragment...it seems to ignore all of the properties except for those that need to be displayed, like it's not actually inserting into the overall DOM string. Considering that the original INPUT from the test case IS embedded in a DIV, just like the inserted INPUTs, I don't know that the real problem here has anything to do with FORM submission, rather the original textual insertion. Refer to the bug I mentioned above where events don't work either.
Oops...here's the URL.
Seems pretty major. Hope I'm not over-scheduling M17. :)
*** Bug 35484 has been marked as a duplicate of this bug. ***
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Additional comment: this also affects the performance of the innerHTML property. If you set the innerHTML and it includes an HTML element with events, the events do not respond.
Updating QA contact.
Bulk reassigning form bugs to Alex
WFM Linux 2002011706. Keith, can you confirm? (Use the testcase I'm about to attach.)
Created attachment 65562 [details] Proper Testcase The previous testcase only allows you to add one thing before it submits, due to the fact that the button type is not specified and defaults to type=submit.
Hell, it's been a long time since this was opened. Reopen if this is still a problem please.
Verified on Build 2001122106 (0.9.7) Win2k
Recommending for closure, in case you would like to get bugs out of the v/wfm state. I was still having problems in one of my web pages, but I moved the FORM element to the outermost point (beside the body tags) and bam, it works. I'm going to assume that I have some badly formed HTML somewhere in that page since I haven't been able to manage a test case that doesn't work!