WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
16641
Acid3 reveals HTMLFormElement.elements fails to update when element name changes
https://bugs.webkit.org/show_bug.cgi?id=16641
Summary
Acid3 reveals HTMLFormElement.elements fails to update when element name changes
Eric Seidel (no email)
Reported
2007-12-28 02:21:10 PST
Acid3 reveals HTMlFormElement.elements fails to update when element name changes From this test: function () { // test 68: changing a dynamic <input> var ok = true; var f = document.createElement('form'); var i = document.createElement('input'); i.name = 'first'; i.type = 'text'; i.value = 'test'; f.appendChild(i); if (i.getAttribute('name') != 'first' || i.name != 'first' || i.getAttribute('type') != 'text' || i.type != 'text' || i.value != 'test' || f.elements.length != 1 || f.elements[0] != i || f.elements.first != i || f.elements.second != null) ok = false; i.name = 'second'; i.type = 'password'; i.value = 'TEST'; if (i.getAttribute('name') != 'second' || i.name != 'second' || i.getAttribute('type') != 'password' || i.type != 'password' || i.value != 'TEST' || f.elements.length != 1 || f.elements[0] != i || f.elements.second != i || f.elements.first != null) ok = false; if (ok) return 5; }, We only fail this check "f.elements.second != i".
Attachments
patch
(11.51 KB, patch)
2007-12-31 17:03 PST
,
Darin Adler
mitz: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2007-12-30 23:13:45 PST
The problem is JSNamedNodesCollection. It caches the nodes at time of creation, and then it's not gone from the DOM cache until a GC. Meaning if any of the nodes change, it's stale. We'll probably move to something more like a NodeList.
Darin Adler
Comment 2
2007-12-31 16:29:22 PST
(In reply to
comment #1
)
> The problem is JSNamedNodesCollection. It caches the nodes at time of > creation, and then it's not gone from the DOM cache until a GC. Meaning if any > of the nodes change, it's stale. We'll probably move to something more like a > NodeList.
I don't think that analysis is correct. Each call to "second" will create a unique JSNamedNodesCollection. The bug here is presumably something in HTMLCollection, not the DOM binding. Perhaps nameCache is not getting invalidated. Perhaps the DOM tree version isn't getting updated when the name is changed.
Darin Adler
Comment 3
2007-12-31 16:35:27 PST
This bug is specific to an HTMLFormElement that is not currently in its owner document. The bug is in the document's DOMTreeVersion mechanism. It only increments if the node is in the document. But the form collection works even for forms that are not "in" the document. The best fix for this is to remove the inDocument() checks at all the call sites for incDOMTreeVersion.
Darin Adler
Comment 4
2007-12-31 17:03:51 PST
Created
attachment 18220
[details]
patch
mitz
Comment 5
2007-12-31 17:08:57 PST
Comment on
attachment 18220
[details]
patch r=me
Darin Adler
Comment 6
2007-12-31 17:17:40 PST
Committed revision 29053.
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