[Webkit-unassigned] [Bug 9508] JavaScript Comparing a form element group to itself returns false.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jan 30 01:52:43 PST 2007


http://bugs.webkit.org/show_bug.cgi?id=9508


sanjay12 at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #12780|                            |review?
               Flag|                            |




------- Comment #10 from sanjay12 at gmail.com  2007-01-30 01:52 PDT -------
Created an attachment (id=12780)
 --> (http://bugs.webkit.org/attachment.cgi?id=12780&action=view)
caching method

This patch implements the "caching" method as discussed above. When a new
DOMNamedNodesCollection is created, it's stored in a hash map, and subsequent
requests for it return a pointer to the same object, instead of creating a new
temp object just for themselves.

Additionally, I moved DOMNamedNodesCollection closer to JSHTMLCollection, and
out of kjs_dom.h. Since it was only ever used internally by JSHTMLCollection,
it doesn't even need to be in a header that's included all over the place, but
can rather be defined in kjs_html.cpp.

One thing that may be a little questionable is the way I mangle the identifier
in order to ensure that multiple forms or pages with the same form group
identifier don't give false positives. Basically, rather than just using the
straight identifier, I take the identifier plus the address of the first node
in the collection (since the nodes contained by the collection are never temp
copies, but always point to the actual form elements). Then I use the
identifier+address as the string key for the hash map. Because the
JSHTMLCollection object itself is very short-lived (it immediately goes out of
scope after returning what it needs to), this seemed like the least roundabout
way to prevent the identifier clashes. But again, I'm definitely open to
suggestion if someone has a better idea.

I've also updated the test case for this bug slightly from the previous patch.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list