Change Panel titlebars to activate the panel on click (rather than minimize).

chrome/browser/ui/panels/docked_panel_strip.cc

Index: chrome/browser/ui/panels/docked_panel_strip.cc
diff --git a/chrome/browser/ui/panels/docked_panel_strip.cc b/chrome/browser/ui/panels/docked_panel_strip.cc
index ad9118f9fe4200452715fab5a05e4bc5e6b19d61..9651609739fac5d1c82fb72f6d5006a744de1d4c 100644
--- a/chrome/browser/ui/panels/docked_panel_strip.cc
+++ b/chrome/browser/ui/panels/docked_panel_strip.cc
@@ -426,6 +426,10 @@ void DockedPanelStrip::DragRight(Panel* dragging_panel) {
 void DockedPanelStrip::EndDraggingPanelWithinStrip(Panel* panel, bool aborted) {
   dragging_panel_current_iterator_ = panels_.end();
 
+  // Ensure dragging a minimized panel did not activate it.
+  if (IsPanelMinimized(panel) && panel->IsActive())
+    panel->Deactivate();

[Dmitry Titov, 2012/04/18 01:49:46]

We should reliably prevent activation while dragging the title-only panel. I
don't think we can guarantee (at least not for all OSes) that in all conditions
the Activate->Deactivate sequence, if it happens, will leave the order of
windows and activation where it was, especially when other apps are in the
picture. 
We should DCHECK here and make sure we don't activate in this case.

[jennb, 2012/04/24 18:47:14]

Moved work-around into PanelBrowserView as it is Windows-specific.

On Windows, mouse down immediately activates a window so there's no opportunity
to prevent activation while dragging a title-only panel. This is only a problem
when drawing attention because after dragging a non-drawing attention minimized
panel, there's an expansion state change from TITLE_ONLY back to MINIMIZED,
which calls Deactivate(). There is no expansion state change after dragging a
minimized panel that is drawing attention, so we're left with an activated
minimized panel. It's an edge case. 

Jian tells me that we can jump through some hoops on Windows to prevent being
activated from a mouse-press while minimized, but that should be attempted in a
separate patch if we attempt it at all.

+
   // Calls RefreshLayout to update the dragging panel to its final position
   // when the drag ends normally. Otherwise, the drag within this strip is
   // aborted because either the drag enters other strip or the drag is
@@ -504,9 +508,8 @@ void DockedPanelStrip::OnPanelTitlebarClicked(Panel* panel,
   DCHECK_EQ(this, panel->panel_strip());
   if (modifier == panel::APPLY_TO_ALL)
     ToggleMinimizeAll(panel);
-
-  // TODO(jennb): Move all other titlebar click handling here.
-  // (http://crbug.com/118431)
+  else
+    panel->Activate();  // Will expand a minimized panel.

[Dmitry Titov, 2012/04/18 01:49:46]

We should activate on mousedown. This is the 'normal' behavior on all OSes and
we do this to brin g'normal' behavior to panels.
Also, on some OSes (all?) the mosuedown is wired to some system action that
activates the window - normally, apps do not need to react to clicks in their
windows by calling some Activate() method... We should just let those things
work (we suppressed them before)
If we don't need to actually Activate() here, we still might want to Expand() a
minimized panel - but we should do that explicitly then, not using the
Activate() method.

[jianli, 2012/04/18 22:18:47]

Just as dimich pointed out, Activate call is not needed on Windows since it is
automatically handled by the system.

[jennb, 2012/04/24 18:47:14]

Removed. See adjustments to Panel::OnTitlebarClicked as a result.

 }
 
 void DockedPanelStrip::ActivatePanel(Panel* panel) {