Bug 1374691 - don't instantiate the panelmultiview and panelview bindings until necessary, r=florian,mconley

MozReview-Commit-ID: L0P1eKxRf3A

--HG--
extra : rebase_source : dc37f06c10b5723bc929179042e7bc4f9d663f21

browser/base/content/browser.css

@@ -104,6 +104,12 @@ panelview {
   -moz-box-orient: vertical;
 }
 
+panel[hidden] panelmultiview,
+panel[hidden] photonpanelmultiview,
+panel[hidden] panelview {
+  -moz-binding: none;
+}
+
 .panel-mainview {
   transition: transform var(--panelui-subview-transition-duration);
 }

browser/components/customizableui/CustomizeMode.jsm

@@ -313,13 +313,19 @@ CustomizeMode.prototype = {
         window.PanelUI.menuButton.open = true;
         window.PanelUI.beginBatchUpdate();
 
-        // The menu panel is lazy, and registers itself when the popup shows. We
+        // The menu panel is lazy, and registers itself when the popup shows.
-        // need to force the menu panel to register itself, or else customization
+        // If it hasn't been opened yet, we need to force the menu panel to
-        // is really not going to work. We pass "true" to ensureReady to
+        // register itself, or else customization is not going to work.
-        // indicate that we're handling calling startBatchUpdate and
+        // We pass "true" to ensureReady to indicate that we're handling
-        // endBatchUpdate.
+        // calling startBatchUpdate and endBatchUpdate.
         if (!window.PanelUI.isReady) {
           await window.PanelUI.ensureReady(true);
+          // Up to now, it will have been hidden, and its XBL bindings won't have
+          // been constructed. Unhiding it won't trigger the construction of
+          // those bindings immediately, but the next layout flush will.
+          // Because we don't want to sync flush layout, we wait for the next
+          // natural style/layout flush.
+          await new Promise(resolve => window.requestIdleCallback(resolve));
         }
 
         // Hide the palette before starting the transition for increased perf.