Both monitors attached to Gigabyte GTX 1060 6GB, Windforce OC Edition
Mon# Res     Size   Port
1  1920x1080 31.5"  HDMI 1080p
2  1920x0180 21.5"  DVI-D

Tests run with hardware acceleration on and off: no change
Tests run with background processing: off

Omitting step 4 and closing maximized window2 on monitor#2;
then open chrome, opens on monitor#2 with odd size.

'Odd size' is nearly maximized: full height vertically, slight, symetrical   screen margin left/right ~6px.  Reported (javascript) inner width/height is: 1904x931.

Odd size also seen, when broken and dragging monitor#2 maximized window to monitor#1, which reflows as odd size on monitor#1.

When similar steps are run with windows apps (Notepad++, Edge), the app always opens maximized.

Step 2 is redundant.  Dragging a tab from the monitor#1 maximized window, is still maximized when dropped on monitor#2.

But the monitor#2 maximized window2 drag back to monitor#1 displays with the odd size on monitor#1.

"Odd size also seen, when broken and dragging monitor#2 maximized window to monitor#1, which reflows as odd size on monitor#1."

Odd size only shows when dragging windows if it has not been corrected. ie: recreate issue, get odd window size, becomes default 'windowed' size. Dragging windows uses default window size.

If resize odd size to normal windowed size, then dragging window2 to monitor#1 uses normal windowed size.

I replicated the effect.  Dual monitor config
left display1: laptop 1600x900, right display2: HDMI 1920x1080,
with Win10 Extended display.

Steps:
Start with windowed chrome on display1 958x730, open new tab, 
drag new tab to display2, maximize: 1920x1080; close display1 chrome,
drag display2 window to display1, get 958x730, maximize: 1600x900, close;
open chrome, opens on display1 at near-max: 1598x900

Also: maximize display1 1598x900 to 1600x900,
drag to display2, becomes near-max 1598x900.

Used: javascript:alert(window.outerWidth + " x " + window.outerHeight);  
to inspect size.

Replicated with Win10 version 1703, Chrome beta 59.0.3071.86
HDMI connected to TV

Able to reproduce issue on Windows 10,checked with version #59.0.3071.104 and latest canary #61.0.3135.4 

The root cause of this failure is likely the use of New Tab page in creating the window before the maximize and close.  The New Tab issues is being worked as bug 733849.  The failure here (this issue) is another side effect of bug 733849.

Suggest: marking 730163 as depends on/blocking on issue 733849.

Reproducing the bug is sensitive to the testors profile.
Any information on the test profile used to replicated the bug would be appreciated.

Alex - My current theory is that the failure is related to way history interacts with the New Tab page.  I have some profiles that produce 0x0
nearly always, sometimes, and almost never.

Were you ever able to see the 0x0 error? 
Usually only once, immediately after the new tab tear off to spawn a new window?

If you have a situation where you can reliably reproduce the 0x0 error 
- or the maximize/close/open:near-max behavior,
would you mind clearing history and seeing if the problem persists?

Thanks, Larry

Simpler single-monitor use case to produce near-max open
0) Using test profile, only default extensions enabled (4 Google Docs ext)
Start page: New tab (default).  New Tab page has 2 thumbnails: Welcome, Webstore. Added bookmark for GitHub winsize (see below)

Near-max open occurs with most profiles.  Using a standard test profile eliminates possible interaction.

1) Chrome windowed: win1
2) Create New Tab tab by clicking right half tab
3) Spawn new window (win2) by dragging New Tab tab to desktop.
4) Close win1 - use top right Xit
5) Maximize win2, observe be-windowed button top right
6) Optional: run winsize to confirm size (see below)
7) Close Win2
8) Open Chrome (from taskbar), opens windowed, slightly less than max,
i.e. near-max, observe windowed state from be-max button, top right
9) Optional: run winsize
10) Maximizing/return to windowed, returns to the near-max size;
initial step1 windowed size is lost.

Javascript winsize diagnostic now available on GitHub:
Run  with https://rawgit.com/LarryLACa/Test/master/WinSizeDebug.htm
View with https://github.com/LarryLACa/Test/blob/master/WinSizeDebug.htm
Improvements: Added best estimate of true outer window size.

Alex: I've been able to replicate the near-max new tab tear-off scenario with a vanilla profile.  You don't need to clear history as I suggested 6/21.

The 0x0 failure is illusive.  I can't force it more than 20% of the time.  It's not surprising that you haven't seen it. See bug 733849 for details.

Regression Testing
Beginning with 58.0.3029.19 (first m58 beta) I see the near-max (single monitor) failure:
opens near-max after last maximize and close.
The failure persists thru canary 61.0.3140.0 (released 6/23)

Thru 57.0.2987.98 (last m57 beta == first m57 stable), open after maximized close, retains the maximized state.

Larry - just reproduced 0x0 error for the first time. Also cleared history and reproduced near max, 0x0 persists.

Gunthert(Alex): Thnx.  Depending on your profile, the 0x0 error is not deterministic, appears maybe 20% of the time.  See bug 733849 for details.

The single monitor near-max failure (Cmt#11) always occurs (since m58).

Hoping to divert bug 733849 efforts here, since single monitor use case is easier/consistent to reproduce.

Any progress on this?? I suffer from this problem too.
Two 1920x1080 monitors, one DVI one HDMI, both 23.5".
DVI monitor is second monitor, not main, but the monitor I use Chrome on mostly.
HDMI monitor is first monitor, main monitor, gaming monitor.
If at any time, my only window of Chrome is maximised on first monitor, the next time I launch it, it will always be weird almost-fullscreen, but not maximised size (on the monitor it was closed on).

What progress?

brycesmi: Basically: no.

This failure mode: (I call it near-max): close the last maximized window, reopen is near-max size but windowed, is one of several failures from a related CR bug 733849 (single monitor Window size error).

CR 733849 got some attention back in September, but stagnated when it could not be reproduced reliably.

As I recall, the workaround for your scenario is pretty straight forward.
Just before you finish: open a new window, close the first (maximized) window, maximize the last remaining window, then close.

The failure is order sensitive and buried (invisible). It depends on when/how you create the chrome windows on each monitor.  Avoid the critical path or do a little extra when you're ready to close, and the problem doesn't show up.

The near-max bug can be demonstrated on a single monitor (as in bug 733849),
but the use case is so rare it's hard to get much attention.

Feel free to comment on 733849.  If you can refocus that effort with a reproducible, single monitor scenario, it may get some attention.

The original Forum thread on the/your dual monitor failure is here:
https://productforums.google.com/forum/#!topic/chrome/tbIXp2sJDDM
It's now closed/locked, but I think it demonstrates how to avoid the problem.

PS: I'm not on the Chrome team.  
Just another enthusiast pushing it along..

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!