Linux/Mac Views: Make BrowserWindow::Show() behave like Windows.

chrome/browser/ui/views/frame/browser_view.cc

Index: chrome/browser/ui/views/frame/browser_view.cc
diff --git a/chrome/browser/ui/views/frame/browser_view.cc b/chrome/browser/ui/views/frame/browser_view.cc
index bea88d4c5dd496122d36e6e00c880d94a7a244f4..37841e32dea16d6f9626fdbab6bd86fdc09e37a9 100644
--- a/chrome/browser/ui/views/frame/browser_view.cc
+++ b/chrome/browser/ui/views/frame/browser_view.cc
@@ -684,6 +684,18 @@ void BrowserView::Show() {
 
   frame_->Show();
 
+  // A similar block also appears in BrowserWindowCocoa::Show().

[Peter Kasting, 2015/03/28 02:35:38]

Nit: I would replace the last sentence of the comment below with this one and
change "Linux Views" below to "other platforms".

Then the comment is just as applicable to both Linux and Mac both now and in any
presumptive Mac Views-based future.

+#if !defined(OS_WIN)

[tapted, 2015/03/28 03:10:57]

add `&& !defined(OS_CHROMEOS)`?

The downside of not excluding ChromeOS is probably minor, but non-desktop Aura
widgets activate synchronously, like Windows.

The same would apply for browser windows on Linux running inside an Ash desktop,
but I doubt it's worth singling that out.

[Peter Kasting, 2015/03/28 03:12:52]

Hmm, is OS_CHROMEOS right then?  It sounds like this has more to do with some
kind of AURA or ASH #define...

[tapted, 2015/03/28 03:35:31]

Yeah - it would be a complexity/correctness tradeoff...

Another option could be to override NativeWidgetPrivate::Activate() (which
*should* be called via the frame_->Show() call just above).
DesktopBrowserFrameAuraLinux (and BrowserFrameMac*) already exist and I think
they already have access to do something like

  DesktopBrowserFrameAura::Activate();
  // comment
  BrowserList::SetLastActive(browser_view()->browser());


*I can keep this on my radar and just worry about Mac later

+  // The Browser associated with this browser window must become the active
+  // browser at the time |Show()| is called. This is the natural behavior under
+  // Windows, but Linux Views will not trigger OnWidgetActivationChanged()
+  // until we return to the runloop. Therefore any calls to
+  // Browser::GetLastActive() will return the wrong result if we do not
+  // explicitly set it here.
+  // Mac Views will likely have the same problem, so do this for Mac as well.

[tapted, 2015/03/28 03:10:56]

yup - activation on Mac is always asynchronous.

+  BrowserList::SetLastActive(browser());
+#endif
+
   force_location_bar_focus_ = false;
 
   browser()->OnWindowDidShow();