From 5223d1d7745052d041ed32fb233a912b5996d7e2 Mon Sep 17 00:00:00 2001
From: Birunthan Mohanathas <birunthan@mohanathas.com>
Date: Thu, 5 Dec 2019 11:37:42 -0600
Subject: [PATCH] fix: Fix compositor recycling when creating new BrowserView
 (#21372)

In #20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also #19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView
---
 shell/browser/api/atom_api_web_contents.cc | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/shell/browser/api/atom_api_web_contents.cc b/shell/browser/api/atom_api_web_contents.cc
index 7d4815db74ff..5da1f7c7ec9e 100644
--- a/shell/browser/api/atom_api_web_contents.cc
+++ b/shell/browser/api/atom_api_web_contents.cc
@@ -399,7 +399,10 @@ WebContents::WebContents(v8::Isolate* isolate,
   // Whether to enable DevTools.
   options.Get("devTools", &enable_devtools_);
 
-  bool initially_shown = true;
+  // BrowserViews are not attached to a window initially so they should start
+  // off as hidden. This is also important for compositor recycling. See:
+  // https://github.com/electron/electron/pull/21372
+  bool initially_shown = type_ != Type::BROWSER_VIEW;
   options.Get(options::kShow, &initially_shown);
 
   // Obtain the session.