WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 22741
innerHTML, forms and images don't play well together
https://bugs.webkit.org/show_bug.cgi?id=22741
Summary
innerHTML, forms and images don't play well together
Dave Moore
Reported
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.
Attachments
Test of failure
(585 bytes, text/html)
2008-12-08 15:25 PST
,
Dave Moore
no flags
Details
Patch to fix
(5.76 KB, patch)
2008-12-08 15:27 PST
,
Dave Moore
no flags
Details
Formatted Diff
Diff
test case david and i wrote
(1.51 KB, text/html)
2008-12-09 14:08 PST
,
Eric Seidel (no email)
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Dave Moore
Comment 1
2008-12-08 15:25:53 PST
Created
attachment 25856
[details]
Test of failure
Dave Moore
Comment 2
2008-12-08 15:27:17 PST
Created
attachment 25857
[details]
Patch to fix
Anantha Keesara
Comment 3
2008-12-08 16:21:15 PST
http://code.google.com/p/chromium/issues/detail?id=4653
Anantha Keesara
Comment 4
2008-12-08 16:21:43 PST
chromium bug:
http://code.google.com/p/chromium/issues/detail?id=4653
Eric Seidel (no email)
Comment 5
2008-12-09 14:08:34 PST
Created
attachment 25897
[details]
test case david and i wrote
Alexey Proskuryakov
Comment 6
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.
Dave Moore
Comment 7
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.
Alexey Proskuryakov
Comment 8
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug