Mac: Fix crash when opening Incognito window

chrome/browser/ui/cocoa/browser_window_controller.mm

 // Copyright 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #import "chrome/browser/ui/cocoa/browser_window_controller.h"
 
 #include <cmath>
 #include <numeric>
 
 #include "base/command_line.h"
@@ skipping 609 matching lines @@
   [self saveWindowPositionIfNeeded];
 
   // TODO(dmaclach): Instead of redrawing the whole window, views that care
   // about the active window state should be registering for notifications.
   [[self window] setViewsNeedDisplay:YES];
 
   // TODO(viettrungluu): For some reason, the above doesn't suffice.
   if ([self isInAnyFullscreenMode])
     [floatingBarBackingView_ setNeedsDisplay:YES];  // Okay even if nil.
 
-  extensions::ExtensionCommandsGlobalRegistry::Get(browser_->profile())->
-      set_registry_for_active_window(extension_keybinding_registry_.get());
+  auto registry =
+      extensions::ExtensionCommandsGlobalRegistry::Get(browser_->profile());
+  if (registry) {
+    registry->set_registry_for_active_window(
+        extension_keybinding_registry_.get());
+  }

[Finnur, 2015/01/23 10:49:38]

Hmm... I'm not sure this is the right fix...

We should be updating the global registry to let it know the registry for the
incognito window is now the active one. Otherwise, it will think the wrong
registry is active and disable shortcuts for the wrong window.

I'm thinking we should adjust the Global Registry to define:

  static const bool kServiceRedirectedInIncognito = true;

... so that the same instance (of the global registry) is returned in both
incognito and regular windows.

[Andre, 2015/01/23 18:24:01]

Thanks Finnur.
When recording a shortcut for an extension, the active window is always the
window that has the settings page, and we don't allow opening settings on
an incognito window. We also cancel recording state when the active window
is switched.
The counterpart code in Views (toolbar_view.cc) does the same check as above.
I'm having problem imagining the problem scenario, do you have one in mind?

 }
 
 - (void)windowDidResignMain:(NSNotification*)notification {
   // TODO(dmaclach): Instead of redrawing the whole window, views that care
   // about the active window state should be registering for notifications.
   [[self window] setViewsNeedDisplay:YES];
 
   // TODO(viettrungluu): For some reason, the above doesn't suffice.
   if ([self isInAnyFullscreenMode])
     [floatingBarBackingView_ setNeedsDisplay:YES];  // Okay even if nil.
 
-  extensions::ExtensionCommandsGlobalRegistry::Get(browser_->profile())->
-      set_registry_for_active_window(nullptr);
+  auto registry =
+      extensions::ExtensionCommandsGlobalRegistry::Get(browser_->profile());
+  if (registry)
+    registry->set_registry_for_active_window(nullptr);
 }
 
 // Called when we are activated (when we gain focus).
 - (void)windowDidBecomeKey:(NSNotification*)notification {
   // We need to activate the controls (in the "WebView"). To do this, get the
   // selected WebContents's RenderWidgetHostView and tell it to activate.
   if (WebContents* contents =
           browser_->tab_strip_model()->GetActiveWebContents()) {
 
     WebContents* devtools = DevToolsWindow::GetInTabWebContents(
@@ skipping 1577 matching lines @@
 
 - (BOOL)supportsBookmarkBar {
   return [self supportsWindowFeature:Browser::FEATURE_BOOKMARKBAR];
 }
 
 - (BOOL)isTabbedWindow {
   return browser_->is_type_tabbed();
 }
 
 @end  // @implementation BrowserWindowController(WindowType)