CrOS Window cycle ui - set widget bounds with initparams to avoid extra

ui/views/widget/widget.cc

 // 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 "ui/views/widget/widget.h"
 
 #include "base/logging.h"
 #include "base/macros.h"
 #include "base/message_loop/message_loop.h"
 #include "base/strings/utf_string_conversions.h"
@@ skipping 1438 matching lines @@
   if (bounds.IsEmpty()) {
     View* contents_view = GetContentsView();
     DCHECK(contents_view);
     // No initial bounds supplied, so size the window to its content and
     // center over its parent if preferred size is provided.
     gfx::Size size = contents_view->GetPreferredSize();
     if (!size.IsEmpty())
       native_widget_->CenterWindow(size);
   } else {
     // Use the supplied initial bounds.
-    SetBoundsConstrained(bounds);
+    SetBounds(bounds);

[Evan Stade, 2016/09/13 17:26:25]

Does this make sense? An alternative would be to just remove the inset in
SetBoundsConstrained for frameless windows.

My best guess is that SetBoundsConstrained is designed to make sure normal
windows are within the work area and adds some "helpful" padding, so it might
not need to be applied to frameless windows.

[sky, 2016/09/13 19:44:02]

This does indeed worry me. Did you look at the history to see if it was added
for a specific type? I'm inclined to think we should only do it for TYPE_WINDOW.

[Evan Stade, 2016/09/13 21:59:33]

Do you mean TYPE_WINDOW_FRAMELESS? I don't really think TYPE_MENU or other
frameless types would want to be forced 10px inside the work area either. For
example, when you have a maximized browser window and you click the app menu,
the menu shouldn't be moved 10px to the left (and in fact it isn't, which is
because MenuHost can still call SetBounds() and circumvent this weird behavior
[1]). It appears that SetBoundsConstrained is only used from one place outside
of Widget: network_config_view.cc.

re: history --- for SetInitialBoundsForFramelessWindow, I suspect it was just
copy-pasted from SetInitialBounds[2]. That was added here[3].

[1]
https://cs.chromium.org/chromium/src/ui/views/controls/menu/menu_host.cc?rcl=...
[2] https://codereview.chromium.org/9250029
[3] https://codereview.chromium.org/8477019
[4] chrome/browser/chromeos/options/network_config_view.cc	

   }
 }
 
 bool Widget::GetSavedWindowPlacement(gfx::Rect* bounds,
                                      ui::WindowShowState* show_state) {
   // First we obtain the window's saved show-style and store it. We need to do
   // this here, rather than in Show() because by the time Show() is called,
   // the window's size will have been reset (below) and the saved maximized
   // state will have been lost. Sadly there's no way to tell on Windows when
   // a window is restored from maximized state, so we can't more accurately
@@ skipping 21 matching lines @@
 
 ////////////////////////////////////////////////////////////////////////////////
 // internal::NativeWidgetPrivate, NativeWidget implementation:
 
 internal::NativeWidgetPrivate* NativeWidgetPrivate::AsNativeWidgetPrivate() {
   return this;
 }
 
 }  // namespace internal
 }  // namespace views