Move LayoutProvider initialization to later in the startup process.

chrome/browser/ui/views/chrome_browser_main_extra_parts_views.cc

Index: chrome/browser/ui/views/chrome_browser_main_extra_parts_views.cc
diff --git a/chrome/browser/ui/views/chrome_browser_main_extra_parts_views.cc b/chrome/browser/ui/views/chrome_browser_main_extra_parts_views.cc
index 556bd754b5435d347b193fd0119b59fb4bcf173c..2a85dcc89c3b1f13038a2fda8ee55b38f1268276 100644
--- a/chrome/browser/ui/views/chrome_browser_main_extra_parts_views.cc
+++ b/chrome/browser/ui/views/chrome_browser_main_extra_parts_views.cc
@@ -73,9 +73,6 @@ void ChromeBrowserMainExtraPartsViews::ToolkitInitialized() {
   if (!views::ViewsDelegate::GetInstance())
     views_delegate_ = base::MakeUnique<ChromeViewsDelegate>();
 
-  if (!views::LayoutProvider::Get())
-    layout_provider_ = ChromeLayoutProvider::CreateLayoutProvider();
-
   SetConstrainedWindowViewsClient(CreateChromeConstrainedWindowViewsClient());
 
 #if defined(USE_AURA)
@@ -90,6 +87,9 @@ void ChromeBrowserMainExtraPartsViews::PreCreateThreads() {
   if (!display::Screen::GetScreen())
     display::Screen::SetScreenInstance(views::CreateDesktopScreen());
 #endif
+
+  if (!views::LayoutProvider::Get())

[Peter Kasting, 2017/04/14 18:14:32]

Is it safe to move the ViewsDelegate creation here too?  If not, I'm worried
that the same code that tries to access that object in the intervening window
could try to access this object, and crash.

Also, if somehow it is safe to keep these separated and code can't crash, this
at least deserves a comment about why it has to be here and not there.

[kylix_rd, 2017/04/14 18:35:26]

I cannot directly answer that question, but my reasoning is as follows:

Any code that relied on ui::MaterialDesignController::Initialize() having been
called would also behave improperly (albeit, it wouldn't likely crash).
Additionally, in the previous model where the LayoutDelegate was lazily created,
would not the same issue Bret outlined have happened?

Even the main browser window initialization must rely on
ui::MaterialDesignController::Initialize() already being called to test the
mode.

I added the creation of the LayoutProvider() into ToolkitInitialized() only
because it previously had been part of ViewsDelegate (along with the underlying
lazily create LayoutDelegate).

[Peter Kasting, 2017/04/14 18:44:49]

That sounds like an argument that we should, in fact, move the ViewsDelegate
creation later.

I think we should try it, but not in this patch.  I added a comment on bug
691894 about this.

+    layout_provider_ = ChromeLayoutProvider::CreateLayoutProvider();
 }
 
 void ChromeBrowserMainExtraPartsViews::PreProfileInit() {