* SUMMARY a new element added to a form by setting innerHTML on an existing form element is not accessible via document.form_name.newElement * STEPS TO REPRODUCE 1. see attached * RESULTS newElement should be accessible * NOTES Works in Firefox Apple Bug: rdar://4031024
Created attachment 2276 [details] Testcase
3/1/05 6:00 PM Darin Adler: I think this is because the elements aren't added to the form's elements array. That's supposed to be done by registerFormElement, which should be called.
The problem originated from the innerHTML implementation. The innerHTML implementation creates a document fragment (that does not contain the containing form). For each node that is created the constructor tries to find the form, but fails. So registerFormElement() is indeed not called. I'll investigate if we can reuse a solution from Konqueror, because it is not affected by this bug.
Created attachment 2329 [details] Possible solution This patch modifies the insertedIntoDocument() function to handle inserting of documentfragments that do not have a dormant form. The patch looks for the correct form and registers the form element.
Comment on attachment 2329 [details] Possible solution works for me.
Comment on attachment 2329 [details] Possible solution Patch looks fine, aside from a couple minor stylistic issues: 1) We don't normally mark our local variables const even though I understand that there is a slight value in doing so to clarify that they can never be modified. 2) We don't normally put the * next to the type, although I don't know if the coding style document mentions this. 3) I personally prefer the style where the declaration is inside the if for code like this. 4) We would normally name this "newForm" rather than "newform", preferring the "intercap" style to the "smush words together" style. Anyway, that's all trivia: r=me.
Created attachment 2418 [details] Updated patch Fixed some minor stylistic issues
We also need an automated test for this. I'll attempt to turn the test case into a layout test, but in the future that should be done before reviewing the patch.
I can't reproduce this problem with Safari 2.0 and WebKit-412 with the test case above. I'm not going to land the patch that fixes this until I can figure out if there's actually a bug it fixes.
This bug was originally reported in WebKit version 185 -- I believe it has already been fixed.
While the patch looks fine, it fixes a bug that does not exist. The attach function already handles this case just fine.
Testcase (In reply to comment #9) > I can't reproduce this problem with Safari 2.0 and WebKit-412 with the test case above. Me neither (WebKit-412.6), but I can reproduce it with ToT so this may have been (re-)broken very recently. In fact, the layout test fast/forms/element-by-name test fails with ToT.
Hmm, no, I can't reproduce any problem at all now. This seems fixed on TOT, and the layout test works too. If you see a problem in the future, please write a new bug report so we can be clear on what specifically is going wrong without any confusing history about how it used to fail a different way in the past.