.
Created attachment 314170 [details] Patch
Attachment 314170 [details] did not pass style-queue: ERROR: Source/WebInspectorUI/ChangeLog:3: ChangeLog entry has no bug number [changelog/bugnumber] [5] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 314172 [details] Patch Oops. Forgot bug :P
Created attachment 314173 [details] Patch Oops. Forgot bug :P
Created attachment 314180 [details] Patch
Comment on attachment 314180 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314180&action=review > Source/WebInspectorUI/ChangeLog:24 > +2017-06-29 Devin Rousso <drousso@apple.com> > + > + Web Inspector: TreeOutlines should mark hasChildren as false when calling removeChildren > + https://bugs.webkit.org/show_bug.cgi?id=173986 Double changelog. Seems fine. r=me
Created attachment 314205 [details] Patch
Comment on attachment 314205 [details] Patch Clearing flags on attachment: 314205 Committed r218983: <http://trac.webkit.org/changeset/218983>
All reviewed patches have been landed. Closing bug.
Re-opened since this is blocked by bug 174042
This transitively affected TreeElement, because some TreeElement operations were TreeOutline operations: appendChild() { return WebInspector.TreeOutline.prototype.appendChild.apply(this, arguments); } insertChild() { return WebInspector.TreeOutline.prototype.insertChild.apply(this, arguments); } removeChild() { return WebInspector.TreeOutline.prototype.removeChild.apply(this, arguments); } removeChildAtIndex() { return WebInspector.TreeOutline.prototype.removeChildAtIndex.apply(this, arguments); } removeChildren() { return WebInspector.TreeOutline.prototype.removeChildren.apply(this, arguments); } removeChildrenRecursive() { return WebInspector.TreeOutline.prototype.removeChildrenRecursive.apply(this, arguments); } selfOrDescendant() { return WebInspector.TreeOutline.prototype.selfOrDescendant.apply(this, arguments); } So this was not the right change. It is being rolled out. Ultimately the underlying issue "TreeOutline's hasChildren doesn't match children.length" still exists. The "hasChildren" property is misleading. It may mean "Doesn't have children yet but needs to populate and will have children", so it is unclear. Lets leave this the way it is and correct any individual issues as needed.
Seems like a good idea to add a test case for the backtraces we temporarily broke. That's a pretty significant regression not to catch by automated testing.