WebUI toolbar crashes with kWebUIToolbarProcessOverheadExperiment enabled #4225

--- chrome/browser/ui/views/toolbar/toolbar_view.cc
+++ chrome/browser/ui/views/toolbar/toolbar_view.cc
@@ -433,11 +433,24 @@ void ToolbarView::Init() {
         base::BindRepeating(callback, browser_, IDC_FORWARD), browser_));
   }
 
-  if (base::FeatureList::IsEnabled(
+  // CEF: WebUIToolbarWebView depends on InitialWebUIManager, which is only
+  // registered on BrowserWindowFeatures for TYPE_NORMAL browsers (see
+  // browser_window_features.cc). CEF hosts using CefBrowserView force the
+  // Browser type to TYPE_POPUP (see chrome_browser_host_impl.cc), so
+  // InitialWebUIManager is never created for them and any WebUIToolbarWebView
+  // instance ends up in a partially-initialized state (crashes without a
+  // defensive null check, and even with one the toolbar fails to paint on
+  // first show). Align the creation guard here with the upstream
+  // BrowserWindowFeatures registration guard so the new WebUI toolbar is
+  // only instantiated when the surrounding infrastructure is guaranteed to
+  // exist.
+  const bool is_normal_browser = browser_->type() == Browser::TYPE_NORMAL;
+  if (is_normal_browser &&
+      base::FeatureList::IsEnabled(
           features::kWebUIToolbarProcessOverheadExperiment)) {
     detached_toolbar_webview_ = std::make_unique<WebUIToolbarWebView>(
         browser_, browser_->command_controller(), /*location_bar=*/nullptr);
-  } else if (features::IsWebUIToolbarEnabled()) {
+  } else if (is_normal_browser && features::IsWebUIToolbarEnabled()) {
     toolbar_webview_ = AddChildView(std::make_unique<WebUIToolbarWebView>(
         browser_, browser_->command_controller(),
         std::move(webui_location_bar)));
2. Add a defensive null check in webui_toolbar_web_view.cc

This mirrors the existing defensive pattern already used elsewhere in the same file (e.g. the TakeToolbarContents() call site):

--- chrome/browser/ui/views/toolbar/webui_toolbar_web_view.cc
+++ chrome/browser/ui/views/toolbar/webui_toolbar_web_view.cc
@@ -512,7 +512,15 @@ void WebUIToolbarWebView::OnPageInitialized() {
     avatar_control_.Initialize();
   }
 
-  InitialWebUIManager::From(browser_)->OnWebUIToolbarLoaded();
+  // CEF: InitialWebUIManager is a BrowserWindowFeatures member that is not
+  // always registered in CEF's chrome-style hosting (e.g. Alloy-inside-Chrome
+  // configurations), so From(browser_) can return nullptr here. Match the
+  // defensive pattern already used elsewhere in this file (see the
+  // TakeToolbarContents() call site) to avoid a null-deref crash right after
+  // the WebUI toolbar page finishes initialization.
+  if (auto* manager = InitialWebUIManager::From(browser_)) {
+    manager->OnWebUIToolbarLoaded();
+  }
 }
Impact
Without these changes, CEF builds that enable the WebUI toolbar experiments will crash or show a blank toolbar in chrome-style hosted windows.

Environment
CEF branch: current master / M-latest
OS: observed on macOS, likely affects all platforms using CEF chrome-style hosting
Relevant feature flags: kWebUIToolbarProcessOverheadExperiment, IsWebUIToolbarEnabled()
Notes
The first patch is the preferred fix because it avoids creating the WebUI toolbar in a context where its dependencies do not exist. The second patch is a defensive fallback that prevents crashes if the toolbar is instantiated through any other path.