Create constrained windows in a hidden state.

chrome/browser/ui/views/constrained_window_views.cc

Index: chrome/browser/ui/views/constrained_window_views.cc
diff --git a/chrome/browser/ui/views/constrained_window_views.cc b/chrome/browser/ui/views/constrained_window_views.cc
index d48427cd9172c6474c186ad7b5fd8de98674e1ab..0287738126e8847735f15651d218b5f93895c666 100644
--- a/chrome/browser/ui/views/constrained_window_views.cc
+++ b/chrome/browser/ui/views/constrained_window_views.cc
@@ -604,7 +604,10 @@ ConstrainedWindowViews::ConstrainedWindowViews(
   }
 
   Init(params);
-
+  // Views default to visible.  Since we are creating a window that is not
+  // visible, mark our View as hidden.  This lets us manage accelerator
+  // registration and focus in a manner consistent with visibility.

[Ben Goodger (Google), 2011/10/26 18:04:58]

Seems like the NCV should just defer registration until its widget is visible,
or that those accelerators should not be reachable for an invisible widget.

[asanka, 2011/10/26 18:46:25]

Yeah. I think that would be better. Views::RegisterPendingAccelerators() already
defers accelerator registration based on IsVisibleInRootView().  Should it
consider the visibility of the widget as well?

In the meantime I'll see if I can get NCV to defer registration.

+  non_client_view()->SetVisible(false);
   wrapper_->constrained_window_tab_helper()->AddConstrainedDialog(this);
 }