FORMs with embedded elements added at run-time [form sub]




HTML: Form Submission
18 years ago
15 years ago


(Reporter: Keith Lesch, Assigned: Alexandru Savulov)



Firefox Tracking Flags

(Not tracked)




(1 attachment, 1 obsolete attachment)



18 years ago
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.

Comment 1

18 years ago
Created attachment 7341 [details]
FORM does not submit all elements after adding some.

Comment 2

18 years ago
See bug 35484.  I believe these are the exact same problem.

Comment 3

18 years ago
Assignee: rods → pollmann

Comment 4

18 years ago
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 

This makes me wonder what's going on with creating a contextual 
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.

Comment 5

18 years ago's the URL.

Comment 6

18 years ago
Seems pretty major.  Hope I'm not over-scheduling M17.  :)
Severity: normal → major
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Target Milestone: --- → M17
*** Bug 35484 has been marked as a duplicate of this bug. ***

Comment 8

18 years ago
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.
Target Milestone: M17 → Future

Comment 9

18 years ago
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.

Comment 10

17 years ago
Updating QA contact.
QA Contact: ckritzer → vladimire
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov


16 years ago
Summary: FORMs with embedded elements added at run-time → FORMs with embedded elements added at run-time [form sub]
WFM Linux 2002011706.  Keith, can you confirm?  (Use the testcase I'm about to
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.
Attachment #7341 - Attachment is obsolete: true
Hell, it's been a long time since this was opened.  Reopen if this is still a
problem please.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 15

16 years ago
Verified on Build 2001122106 (0.9.7) Win2k

Comment 16

15 years ago
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!
You need to log in before you can comment on or make changes to this bug.