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

[bugzilla-daemon at webkit.org]

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





------- Comment #7 from darin at apple.com  2007-01-23 09:01 PDT -------
(In reply to comment #6)
> (In reply to comment #3)
> > While it certainly would be possible to cache requests for form groups in the
> > HTMLFormElement, the issue becomes that if we don't cache every single unique
> > request for the life of the HTMLFormElement, then you potentially could have a
> > comparison occur much later that fails when it shouldn't.
> 
> I don't agree with this comment. There's no problem creating a design where the
> collection is registered with the form; the form points to it and when the
> collection is destroyed the pointer in the form gets cleared.
> 
> We don't need to make any change to the collection lifetime at all to do this
> -- we just need to add a pointer to HTMLFormElement and add the code to the
> collection class to clear this pointer when the collection is deallocated. I
> think this change is simple and practical and probably a better choice than
> adding the ability to do equality comparison to the JavaScript binding.

I studied this more, and I am not sure what I said is right.

It's JSHTMLCollection that would need to keep track of DOMNamedNodesCollection
objects it creates, not HTMLFormElement, because it's the class that creates
the collections. We'd have to add a map of property names to
DOMNamedNodesCollection and store both a pointer to the JSHTMLCollection and
the property name in the DOMNamedNodesCollection objects. Then when a
DOMNamedNodesCollection was destroyed it would call back to the
JSHTMLCollection so it could remove it from the map, and when a
JSHTMLCollection was destroyed it woud disconnect itself from all the
DOMNamedNodesCollection objects still in the map. If we did this, I'd suggest
moving DOMNamedNodesCollection closer to JSHTMLCollection, probably renaming
it, and making the two classes more-closely-associated to accomplish this. I
think it's not all that difficult to make this work.

Specifics of this case aside, I think it's a reasonable to consider making
equality comparison something that JSObject subclasses can customize. I am sad
this came up *after* we defined the C API, because clearly we'd want to be able
to do this from C too.


-- 
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.