[Webkit-unassigned] [Bug 19762] Crash in svg/webarchive/svg-cursor-subresources.svg

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=19762


darin at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com




------- Comment #6 from darin at apple.com  2008-07-06 20:04 PDT -------
(In reply to comment #4)
> A different approach would be to
> clear the whole element id map before calling removeAllChildren, but I am not
> sure if that would be right.

I think that would be an acceptable change. But I also think it should be
illegal to try to get an element by ID while the document is being torn down.
Walking the DOM would also be bad during that time. I think we should to add
code to Document to ASSERT that getElementById is not used that way.

The real problem here is that CSSCursorImageValue gets a cursor element by ID
multiple times and assumes that it's the same one. There's no guarantee that
the same ID will lead to the same element when the CSSCursorImageValue is
destroyed and when cachedImage is called as when updateIfSVGCursorIsUsed was
called. A new element could have been added earlier in the document with the
same ID. In fact, we should construct a test case like this.

The SVGElement needs to use a pointer of some sort to record the
SVGCursorElement it got associated with.

I also don't understand how we're guaranteed that the elements in
m_referencedElements are all still present when CSSCursorImageValue is
destroyed. We can't just store a pointer to an element and hope that it won't
be removed!

I also don't see any code to handle the case where the value of
CSSCursorImageValue is changed with a setStringValue call. That could change
the cursor identifier -- we'd need code to remove it from the old element.


-- 
Configure bugmail: https://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.