RESOLVED FIXED 99211
When ScrollingStateNodes are destroyed, they should be removed ScrollingCoordinator's HashMap
https://bugs.webkit.org/show_bug.cgi?id=99211
Summary When ScrollingStateNodes are destroyed, they should be removed ScrollingCoord...
Beth Dakin
Reported 2012-10-12 14:44:53 PDT
There is a FIXME in ScrollingCoordinatorMac::detachFromStateTree() that says: // FIXME: removeNode() will destroy children, and those children might still be in the HashMap. // This will be a big problem once there are actually children in the tree. This bugs is to track resolving that FIXME.
Attachments
Patch (5.89 KB, patch)
2012-10-12 14:51 PDT, Beth Dakin
no flags
Patch (6.07 KB, patch)
2012-10-12 16:49 PDT, Beth Dakin
sam: review+
Beth Dakin
Comment 1 2012-10-12 14:51:52 PDT
Brady Eidson
Comment 2 2012-10-12 16:25:00 PDT
Comment on attachment 168489 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=168489&action=review > Source/WebCore/page/scrolling/ScrollingStateTree.cpp:58 > + // Copy and clear the array of node IDs representing nodes that have been removed since the last > + // time we committed the tree. > + size_t size = m_nodesRemovedSinceLastCommit->size(); > + for (size_t i = 0; i < size; ++i) > + treeState->didRemoveNode(m_nodesRemovedSinceLastCommit->at(i)); > + m_nodesRemovedSinceLastCommit->clear(); I don't see where the copy is that the comment alludes to. I might be missing something here: doesn't didRemoveNode() just call back in to the same m_nodesRemovedSinceLastCommit?
Beth Dakin
Comment 3 2012-10-12 16:49:28 PDT
Beth Dakin
Comment 4 2012-10-12 16:52:01 PDT
Note You need to log in before you can comment on or make changes to this bug.