Bug 1636227 - Don't reset _sameProcessAsFrameLoader on first browser initialization. r=Gijs

LazyFC changes the way we initialize browsers in a subtle way which is
important for print preview and PiP.

When creating a print preview browser / PiP, we rely on getting the right
process via _sameProcessAsFrameLoader. This is set very early on the
lifetime of the browser element, after it's upgraded but before its
connectedCallback() calls.

What happens with LazyFC is that we append the browser to the document,
then set its sameProcessAsFrameLoader, then initialize the browser from
connectedCallback(). That calls resetFields() _after_ setting the
_sameProcessAsFrameLoader, which clears it out, not good.

Without LazyFC we initialize it via frame construction, as soon as the
browser is attached to the document, so all ends up working out.

Explicitly avoid clearing this field out if not initialized yet, instead
of the hasOwnProperty check which was for the very same thing, just
about XBL initialization.

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

toolkit/content/widgets/browser-custom-element.js

@@ -302,8 +302,14 @@
        * Weak reference to an optional frame loader that can be used to influence
        * process selection for this browser.
        * See nsIBrowser.sameProcessAsFrameLoader.
+       *
+       * tabbrowser sets "sameProcessAsFrameLoader" on some browsers before
+       * they are connected. This avoids clearing that out while we're doing
+       * the initial construct(), which is what would read it.
        */
-      this._sameProcessAsFrameLoader = null;
+      if (this.mInitialized) {
+        this._sameProcessAsFrameLoader = null;
+      }
 
       this._loadContext = null;
 
@@ -1283,16 +1289,6 @@
         var securityUI = this.securityUI; // eslint-disable-line no-unused-vars
       } catch (e) {}
 
-      // tabbrowser.xml sets "sameProcessAsFrameLoader" as a direct property
-      // on some browsers before they are put into a DOM (and get a
-      // binding).  This hack makes sure that we hold a weak reference to
-      // the other browser (and go through the proper getter and setter).
-      if (this.hasOwnProperty("sameProcessAsFrameLoader")) {
-        var sameProcessAsFrameLoader = this.sameProcessAsFrameLoader;
-        delete this.sameProcessAsFrameLoader;
-        this.sameProcessAsFrameLoader = sameProcessAsFrameLoader;
-      }
-
       if (!this.isRemoteBrowser) {
         // If we've transitioned from remote to non-remote, we no longer need
         // our RemoteWebProgress or its associated manager, but we'll need to