Bug 1839066 - Make nsTreeBodyFrame::SetView deal with setting the same view. r=mak

This actually fixes the bug. The issue is that we end up with
nsITreeView.setTree(null) then nsITreeView.setTree(<tree>).

This code deals with the first call:

  https://searchfox.org/mozilla-central/rev/c936f47f3a629ae49a4d528d3366bf29f2d4e4a7/browser/components/places/content/treeView.js#1651

But the later call doesn't restore the state properly and a bunch of nodes end
up unparented. That might be worth fixing on its own...

This is probably a long/forever-standing bug that was uncovered by different
amount of reflow calls.

Depends on D181379

Differential Revision: https://phabricator.services.mozilla.com/D181380

layout/xul/tree/nsTreeBodyFrame.cpp

@@ -452,6 +452,10 @@ nsresult nsTreeBodyFrame::GetView(nsITreeView** aView) {
 }
 
 nsresult nsTreeBodyFrame::SetView(nsITreeView* aView) {
+  if (aView == mView) {
+    return NS_OK;
+  }
+
   // First clear out the old view.
   nsCOMPtr<nsITreeView> oldView = std::move(mView);
   if (oldView) {