Choose the right window to switch to when a panel is deactivated on Windows.

chrome/browser/ui/panels/native_panel.h

Index: chrome/browser/ui/panels/native_panel.h
===================================================================
--- chrome/browser/ui/panels/native_panel.h	(revision 104349)
+++ chrome/browser/ui/panels/native_panel.h	(working copy)
@@ -87,6 +87,9 @@
   // Verifies, on a deepest possible level, if the Panel is showing the "Draw
   // Attention" effects to the user. May include checking colors etc.
   virtual bool VerifyDrawingAttention() const = 0;
+  // Verifies, on a deepest possible level, if the titlebar of the Panel is
+  // being painted correctly per its active state.
+  virtual bool VerifyTitlebarPaintedAsActive(bool as_active) = 0;

[Dmitry Titov, 2011/10/07 20:29:15]

Does it verify that the panel is actually active or that the color of the
titlebar is correct? It's not clear from the description. If it is verifying
that the panel is really active, we could name the method VarifyIsActive() and
implement it by checking the color of titlebar. It could be a different check on
another platform.

[jianli, 2011/10/07 22:01:54]

We want to verify that the titlebar is painted correctly per its active state.
This is the reason I name it as ***PaintedAsActive. Checking whether the panel
is active can be done by calling Panel::IsActive.

[Dmitry Titov, 2011/10/07 22:26:41]

Same logic here as VerifyDrawingAttention() - the method is actually implemented
differently on various platforms. On Views, it checks for colors, on OSX, it
checks for internal flag. It makes sense to name the method by 'what' it does
rather then 'how exactly does it do that'. In this particular case, you verify
that the native panel actually, really and for sure is drawing 'active'
decorations. The 'how' is 'by changing the color of the titlebar'. On OSX, we
might again check for internal flag because the colors are not pulled until we
actually draw real pixels.

 };
 
 #endif  // CHROME_BROWSER_UI_PANELS_NATIVE_PANEL_H_