[Webkit-unassigned] [Bug 103911] Web Inspector: more robust treeoutline.findTreeElement

Wed Dec 5 10:30:47 PST 2012

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

--- Comment #9 from johnjbarton <johnjbarton at chromium.org>  2012-12-05 10:33:13 PST ---
In my original report I cited a 100% CPU problem tracked down to the code patched here. I claimed that incorrect remote data could cause the algorithm to recurse. 

With the patched WebInspector I attempted to reproduce the remote data problem. However I think my understanding of the issue was not quite correct.

Here are some outputs from the command line when we are in the patched code just after calling treeElement.onpopulate():

representedObject._nodeName
"BODY"
treeElement.representedObject._nodeName
"HTML"
treeElement.children.map(function(c){return c.representedObject._nodeName;});
["HEAD", "BODY", "HTML"]

So for an HTML tag, the representation has three children: HEAD, BODY, and -- surprise to me -- HTML. Evidently the closing tag is represented as child treeElement:

treeElement.representedObject === treeElement.children[2].representedObject
true

Thus the DOMNode data is a tree, but the treeoutline never is.

Suppose we have 
<html><head><body><div></div></body></html>
and suppose we have the body treeElement built but not the div. In the old algorithm we visit children of HTML, and we should find BODY because isAncestor(BODY, DIV) should be true. But any failure that might cause this test to fail will result in infinite recursion because the last child will always be true, eg isAncestor(HTML, DIV).

This does not explain how the test can fail but it does explain why my testing to verify that the treeoutline is itself a tree fails.

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