That is intentional behavior. +bettes@

Thanks for the quick reply. We should follow our window management logic across window types ideally. Curious to hear why we would want settings to open in  different size

So, to be clear, we're agreed that once a user adjusts the window state (maximized vs restored) or size we should always return to that state/size whenever it is opened. This bug is only about the default size of the window before the user has adjusted it.

It sounds like we should have a fixed default size, but if that takes up more than some percentage of the screen we should simply maximize the window.

@skuhne could you share the logic we have around the default window sizing for the browser and assign back to me?

I need to look that up again - but we apply the same logic for all ChromeOS windows (as of now). If I remember correctly it was a percentage of the screen until the screen gets too big, then we limited it to something like 1440 at a maximum size. Will check on Monday when back into the office.

I checked - but unfortunately there was no document outlining the current behavior now - and there are plenty of corner cases.

[Part of the placement logic is here: https://cs.chromium.org/chromium/src/ash/wm/window_positioner.cc?rcl=44bb60e9a2f0eb573f0c4c1e7742fa53a7ab23b9&l=223]

The final result is complicated as it got tweaked dependent on corner cases over time (2012 to 2014) + the code got rewritten / moved many times.


1. Default sizes
  This depends on the window (some windows have minimum / maximum sizes, or multiple of character sizes (e.g. console windows which use a certain font).
  If total freedom is allowed, the window will be the size of the screen minus a border (16px) around to allow to show part of the desktop.
  (Users like to see their self set desktop!!).
  One special case: We added an upper limit for the width of the window (1100 pixels) since most web pages are not expecting more space.
  This way you get on a big screen an easy way to have two windows side by side.

2. Default location
  usually in the middle of the screen if you have a single window.
  If there is already one window, that window gets moved to the left / right side and the new one to the opposite one.
  This way both will become visible.
  Note: Once the other window closes the remaining window will be shifted back into the middle of the screen.

3. Default is nice - BUT if the window got created earlier and the user moved / resized it, that is taken into consideration!
  In this case the size will be restored to the previous size.
  In this case the position will be restored to the previous position if there is no other window on the screen.
  In this case the position might be shifted to a new position if there is only a single other window on the screen.
  
4. Specials...
  I said already there are specials. One is that if the current top window is maximized already, a new window will be maximized as well.
  This is done as we expect that the user might only want to work maximized.

  Plenty more.

I don't think that you want to have the full (current) logic be written up here, so I leave it at that. Please let me know if there are any more questions?

>> If total freedom is allowed, the window will be the size of the screen minus 
>> a border (16px) around to allow to show part of the desktop.
>>  (Users like to see their self set desktop!!).
>>   One special case: We added an upper limit for the width of the window (1100
>> pixels) since most web pages are not expecting more space.

Wow, this is def old behavior. At some point about 3 years ago we decided all windows should maximize if screen size is below. See this bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=168178


Large Screens (> 1450 wide or tall)    
>> Windows default to desktop mode, 1100 px wide.

Medium & Small screens (< 1450 wide or tall)
>> Windows are organized/maximized, launcher/chrome showing
 

+Omri to help out. Folks, we should fix this based on what was specced

From reading this thread, there are two action items we should take upon ourselves:
1. [short term] Move settings to behave as spec'd, specifically the maximize behavior on smaller screens.
2. [long term] go over all the logic and simplify it.

Does anyone disagree with these two items? If not, Stefan, would you like to go over the logic for 2. together? 

For (1), could you elaborate as to what "as speced" means? Specifically, could you provide a link to a spec? :)

Omri -- happy to discuss the context here. From stevenjb/skuhne, it sounds like there's different logic in different places (browser windows, app windows, ARC++ windows), and it's unclear which pieces line up with the logic Kuscher linked to (the logic in #5 has something different). The spec also needs some additional detail, eg. window height depending on screen size.

Just a reminder that this is an M63 beta blocker. M63 goes beta 10/26. 

OK, just for kuscher@, I tracked down where we intentioanlly changed the definition of a "large screen" from 1450 -> 640 (to basically disable it) -> 1366 (the current value):

->640 ( issue 173247 )
https://chromiumcodereview.appspot.com/12285011

-> 1366 ( issue 177817 )
https://chromiumcodereview.appspot.com/14172010

Given that this was an intentional decision made in 2013, I really don't think that changing the behavior should be release-block-beta for 63.

This is also why a comment in a CL is not a good source of "documentation" :P

I agree on not blocking beta on this, but we should address this.
Tom, would you like to take ownership of coming up with a proposal?