Fix multiple problems with omnibox text handling across focus changes.

chrome/browser/ui/cocoa/browser_window_cocoa.mm

 // Copyright (c) 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.
 
 #include "chrome/browser/ui/cocoa/browser_window_cocoa.h"
 
 #include "base/bind.h"
 #include "base/command_line.h"
 #include "base/logging.h"
 #include "base/mac/mac_util.h"
@@ skipping 287 matching lines @@
 }
 
 void BrowserWindowCocoa::UpdateLoadingAnimations(bool should_animate) {
   // Do nothing on Mac.
 }
 
 void BrowserWindowCocoa::SetStarredState(bool is_starred) {
   [controller_ setStarredState:is_starred ? YES : NO];
 }
 
+void BrowserWindowCocoa::OnActiveTabChanged(content::WebContents* old_contents,
+                                            content::WebContents* new_contents,
+                                            int index,
+                                            int reason) {
+  // TODO(pkasting): Perhaps the code in
+  // TabStripController::activateTabWithContents should move here?  Or this
+  // should call that (instead of TabStripModelObserverBridge doing so)?  It's
+  // not obvious to me why Mac doesn't handle tab changes in BrowserWindow the
+  // way views and GTK do.
+}
+
 void BrowserWindowCocoa::ZoomChangedForActiveTab(bool can_show_bubble) {
   [controller_ zoomChangedForActiveTab:can_show_bubble ? YES : NO];
 }
 
 gfx::Rect BrowserWindowCocoa::GetRestoredBounds() const {
   // Flip coordinates based on the primary screen.
   NSScreen* screen = [[NSScreen screens] objectAtIndex:0];
   NSRect frame = [controller_ regularWindowFrame];
   gfx::Rect bounds(frame.origin.x, 0, NSWidth(frame), NSHeight(frame));
   bounds.set_y(NSHeight([screen frame]) - NSMaxY(frame));
@@ skipping 444 matching lines @@
   // further, both by another H, i.e. WebContentsView's height becomes
   // A.height() + H and RenderWidgetHostView's height becomes A.height() + 2H.
   // Strangely, the RenderWidgetHostView for the previous navigation entry also
   // gets enlarged by H.
   // I believe these "automatic" resizing are caused by setAutoresizingMask of
   // of the cocoa view in WebContentsViewMac, which defeats the purpose of
   // WebContentsDelegate::GetSizeForNewRenderView i.e. to prevent resizing of
   // RenderWidgetHostView in (2) and (3).
   return 0;
 }