Hack to fix Panel focus issues on Mac.

chrome/browser/ui/panels/panel_window_controller_cocoa.mm

Index: chrome/browser/ui/panels/panel_window_controller_cocoa.mm
diff --git a/chrome/browser/ui/panels/panel_window_controller_cocoa.mm b/chrome/browser/ui/panels/panel_window_controller_cocoa.mm
index 036ed821ff7b131bc87f291f6ed90073353b262d..93fd1652bed3abe8a01d1b786dcc8e0a03be697a 100644
--- a/chrome/browser/ui/panels/panel_window_controller_cocoa.mm
+++ b/chrome/browser/ui/panels/panel_window_controller_cocoa.mm
@@ -188,6 +188,16 @@ enum {
   // Shows the window without making it key, on top of its layer, even if
   // Chromium is not an active app.
   [window orderFrontRegardless];
+  // TODO(dcheng): Temporary hack to work around the fact that
+  // orderFrontRegardless causes us to become the first responder. The usual
+  // Chrome assumption is that becoming the first responder = you have focus, so
+  // we always deactivate the controls here. If we're created as an active

[Dmitry Titov, 2011/10/26 22:26:31]

Not clear... Window gets orderFrontRegardless -> who become the first responder?
-> who will have focus? -> why  we deactivate when we have focus? 
It feels like not enough context for understanding.

Maybe have a good description in a bug and only rever from here to the bug link?

+  // panel, we'll get a NSWindowDidBecomeKeynotification and reactivate the web

[Dmitry Titov, 2011/10/26 22:26:31]

NSWindowDidBecomeKeynotification - need space

+  // view properly. See crbug.com/97831 for more details.
+  TabContents* tab_contents =
+      windowShim_->panel()->browser()->GetSelectedTabContents();
+  if (tab_contents)
+    tab_contents->GetRenderWidgetHostView()->SetActive(false);
   [window setFrame:frame display:YES animate:YES];
 
   [contentView setAutoresizesSubviews:YES];