Bug 22741

Summary: innerHTML, forms and images don't play well together
Product: WebKit Reporter: Dave Moore <davemoore>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, davemoore
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows XP   
Attachments:
Description Flags
Test of failure
none
Patch to fix
none
test case david and i wrote none

Description Dave Moore 2008-12-08 15:24:46 PST
If you have a form that contains a span that contains an img tag with a name and id, and replace that img with another one, with the same name but a different id, any javascript that accesses that img through the form (form.image.id) will get the old value. Accessing the img through the document will get the new value.

This behavior is consistent in IE6, Safari and Chrome. In FF and IE7 you get the new value using either path to the image.

In HTMLFormElement there is a vector called imgElements that gets initialized when the form is created. As far as I can tell this vector is never updated when the innerHTML is set.

HTMLParser has a notion of the current form, contained in the instance variable m_currentFormElement. This is used when an HTMLImageElement is created to allow imgElements to be updated. When innerHTML is set on a span within the form there is no way for this variable to be initialized, so the image can't be added to the form's imageElements.

I've modified HTMLElement, HTMLImageElement, HTMLParser and HTMLTokenizer to support initializing the m_currentFormElement to the form that contains the HTMLElement which is having its innerHTML set. I remove the image from the form when it is removed from the document and add it to the form when it's added to the document. In the attached file you can see the failure when the two numbers shown (one for document.pic.id and one for form.pic.id) don't match. 

One additional thing I've noticed is that the HTMLImageElement is never destroyed when removed from the document. If it was, it would have been removed from the form as well. I believe there is an old IE behavior that says that if an element is referenced by name at some point then it has to be able to be referenced by that name later, even if removed from the document. Perhaps this is to allow for that.
Comment 1 Dave Moore 2008-12-08 15:25:53 PST
Created attachment 25856 [details]
Test of failure
Comment 2 Dave Moore 2008-12-08 15:27:17 PST
Created attachment 25857 [details]
Patch to fix
Comment 3 Anantha Keesara 2008-12-08 16:21:15 PST
http://code.google.com/p/chromium/issues/detail?id=4653
Comment 4 Anantha Keesara 2008-12-08 16:21:43 PST
chromium bug: http://code.google.com/p/chromium/issues/detail?id=4653
Comment 5 Eric Seidel (no email) 2008-12-09 14:08:34 PST
Created attachment 25897 [details]
test case david and i wrote
Comment 6 Alexey Proskuryakov 2008-12-10 04:15:48 PST
Is this patch proposed for review? I'm not sure, because it doesn't even have a ChangeLog.

If it is, please mark it as such by clicking Edit link to the right and setting review? flag.
Comment 7 Dave Moore 2008-12-10 08:48:12 PST
Eric and I developed a better test case that shows some of the edge cases. I'm going to work on an alternate solution and then propose that.
Comment 8 Alexey Proskuryakov 2010-06-11 10:55:15 PDT
I think that this was fixed as part of fixing bug 34076.

Landed the test in r61026 - I'm not sure if it actually covers anything that hasn't been covered already, but it won't hurt.