The only place nsIContent::ReplaceChildAt is used is when someone calls nsIDOMNode::ReplaceChild. However that function is called very rarly, both on the web and in our chrome. And while we in theory can save cycles by having a separate replace-path, the place where we can save most cycles, the nsCSSFrameConstructor, doesn't really take advantage of this. And it's very debatable if it should seing how rarly it's used. Also, since the codepath is so rarly used there's a big risk for bugs. Bug 193298 is one example. Patch removing nsIContent::ReplaceChildAt and nsIDocumentObserver::ContentReplaced comming up.

I very much doubt I'll be able to review this until I come back from my trip (early April).

That's fine, the tree won't unfreeze until then anyway

Comment on attachment 143977 [details] [diff] [review] patch to fix sr=jst

Comment on attachment 143977 [details] [diff] [review] patch to fix >Index: content/base/src/nsGenericElement.cpp >@@ -2883,22 +2845,15 @@ nsGenericElement::doReplaceChild(nsICont > nsCOMPtr<nsIContent> oldContent(do_QueryInterface(aOldChild, &res)); > >- if (NS_FAILED(res)) { Don't bother writing to res if you won't check it, ok? r=bzbarsky with that change. Looks good.

checked in, thanks for reviews!