Bug 3481 – form elements added via innerHTML are not accessible via xpath style syntax

• Status: VERIFIED
• Resolution: WORKSFORME
• Component: Forms

[Stuart Morgan]

* 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

[Stuart Morgan]

Created attachment 2276 [details]
Testcase

[Stuart Morgan]

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.

[Niels Leenheer (HTML5test)]

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.

[Niels Leenheer (HTML5test)]

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.

[Joost de Valk (AlthA)]

Comment on attachment 2329 [details]
Possible solution

works for me.

[Darin Adler]

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.

[Niels Leenheer (HTML5test)]

Created attachment 2418 [details]
Updated patch

Fixed some minor stylistic issues

[Darin Adler]

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.

[Darin Adler]

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.

[Darin Adler]

This bug was originally reported in WebKit version 185 -- I believe it has already been fixed.

[Darin Adler]

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.

[Darin Adler]

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.