The use case is rare enough and the impact minor enough that few users would ever recognize the problem.  There is a related use case extension: after tearing off the NT page to create a new window, the first URL might encounter bad win size args - the primary motivations for logging the error

Related bad behavior.  There are at least 2 additional bad extended use cases:
1) Spawn window from NT, maximize, close original win2 then the new win2,
Open chrome: does opens windowed (max width-10px).  See  bug 730163 , which is for a dual monitor config, but the same problem can be seen on a single monitor.
2) Spawn several NT windows recursively, each from the last spawned window, all windows created with the original size.  Close in the order launched: original window first, last spawned window last.  Open chrome, opens 16px narrower than when closed.  Usually 2 spawned windows is enough to trigger the narrowing.

If someone works this CR, I can provide details, screen shots, etc.

The 0x0 failure is hard to reproduce and cannot be reproduced consistently.  Some profiles get 0x0 always, even with extensions disabled.

Other profiles always report oversize.

Some profiles report oversize when the trigger extension is disabled, but disabling the extension after enable is not, by itself, enough to restore the oversize value. PC shutdown or other extension manipulations may be required to get back to oversize.

Details available on request.

The 14px too wide assessment is based on the AltPrtScrn screenshot pasted to paint, on Win10.  What I used was the 1px Chrome frame, left and right, to calculate outerWidth.  I assume this is the correct usage for outerWidth.  If not.. then I'm still left with the other 2 anomalous behaviors.

Re: reproducing 0x0 size: Only happens when winsize runs in torn-off NewTab tab, i.e. the first and only tab in the new window.  Otherwise winsize reports oversize in any other tab, or in first tab after a refresh or anytime later.

Launch with CL args produces similar effect: 
outerWidth, outerHeight matches CL args, 
actual size is --14px wide, --7px high.

Use   arg                       JS       AltPrtScrn
--window-size=760,400           760x400  746x393
--cast-inital-screen-width=700
--cast-inital-screen-height=400 760x400   746x393

Able to reproduce the issue on windows 7 using chrome version 59.0.3071.86, 60.0.3112.24 & 61.0.3134.0 with the below steps

1. Opened WinSizeAlert.htm on chrome
2. create a New Tab by clicking empty right end half-tab.
3. Drag the New Tab tab off the tabstrip to create a new window
4. Observed the Window outer/inner : 0x0

But Some times when we open the WinSizeAlert.htm first time on chrome itself shows the output as Window outer/inner : 0x0
Hence unable to find the bisect for this issue as the issue is not consistently reproducible.

larrylaca818@If possible please provide any other sample repro case which reproduces consistently will help us to triage it further.

Thanks,

kavvaru@ Thanks.  There are many use cases demonstrating 
a) the 0x0 behavior (sometimes) and 
b) outerWidth & outerHeight oversized (always).

Catching a) is temperamental and depends on the profile initialization.
It only shows up on first use.  Refreshing the winsize tab always reports a value (albeit oversized).  Toggling a few extensions off/on, doing a reset all, etc. is sometimes enough to make the profile healthy.  Once healthy, initial winsize 0x0 is not likely to reappear, then 10 sessions later I'll get a 0x0 size.

Another 0x0 use case (background processing always off)
Settings: Startup: New Tab; 
close chrome, all profiles, all windowed at last close;
winsizeAlert.htm saved as bookmark
open chrome, 1st tab is NT
run winsize from bookmark: get 0x0

At one point I thought it was related to the thumbnails (sites) shown on the NT page.  My minimal test case has only 3, Google Docs, Google Welcome, Chrome webstore (see attached).  Signing out/in of the Google Docs page (without Chrome signout), helped in triggering/healing the 0x0 value, but not consistently.

Regression tests:
57.0.2987.98, 54.0.2840.71 shows 
  b) oversized outerWidth, Height, always but 
  a) never 0x0.
So much has changed in the profile handling since m54, that my 'no 0x0' is unreliable.  When toggling between versions, with my same test profiles, the profiles get repaired with the back/forward migration, which is probably enough to make winsize healthy.

Since the b) oversized outerSize has been present since M54, it doesn't seem to have much impact.

Since a) 0x0 is related to profile initialization/updates you might want to look at bug 130656 which has a good discussion of profile/extension interactions.

Deleted: LAlt NT GDoc blue dot.png 52.8 KB

	LAlt NT GDoc blue dot.png 52.8 KB View Download

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re: use cases and reproducibility

I believe these are equivalent (and unstable) 0x0 use cases:
(always: background processing off, close all chrome sessions, launch from taskbar)
1) settings/start/continue last; close with 1 winsize tab, open 
2) settings/start/New Tab; run winsize, close, open
3) open New Tab tab, tear off, run winsize.

The low reproducibility depends on the profile.
I have one profile that always gets 0x0, 
another that never shows 0x0
another test profile with minimal features from the good and bad
  that I can force to fail (mostly) and then goes healthy again..

For cmt#12, use case 3 == cmt#9 use case, with my profile that consistently detects the outersize 0x0
58.0.3029.81 shows 0x0
57.0.2987.98 shows oversize value
50.0.2661.26 shows oversize value (pre MD)

The oversize value (outerWidth, outerHeight) exists for all tabs, no matter how created.

I believe it's the 0x0 New Tab related use case that has user impacts in some cases.

Other use cases that sometimes show 0x0
open chome, start set for New Tab,
open 3 more New Tab tabs from the tabstrip: tabs2-4
start with tab4, work back to tab1, run winsize in each
  one may show 0x0
similar: have 4 New Tab pages open, working right to left:
  run winsize, back/forward, 1 or more times
  one of the forwards (returns to winsize) may eval as 0x0

The probability of forcing a 0x0 value is < 10% for most profiles.

Tested in Edge (Microsoft Edge 40.15063.0.0, Microsoft EdgeHTML 15.15063)
with WinSizeDebug.htm, run from favorites (see attached)

Use case: open New Tab tab from tab strip with '+', run winsize from favs.
The window.outerWidth and window.outerHeight refs cause the document.write stmts to fail silently - no text is written.  Hide/disable the two .outer stmts in WinSizeDebug to demonstrate the effect. 

On refresh the JS displays the sizes.   
The reported size is +14px too wide and 7px too high.  
See attached.

Chrome does a 'better' job: reporting 0, instead of failing succeeding doc.write stmts.

Deleted: Edge winsize 760x377.png 11.7 KB

	Edge winsize 760x377.png 11.7 KB View Download

Deleted: WinSizeDebug.htm 684 bytes

WinSizeDebug.htm 684 bytes View Download

Able to reproduce the issue on windows 10 using latest chrome version #61.0.3135.0 but unable to reproduce in latest stable #59.0.3071.104.

Following are the steps followed to reproduce the issue.
------------
1. Opened WinSizeDebug.htm (provided in comment #16) in chrome.
2. Create a New Tab by clicking empty right end half-tab.
3. Dragged the New Tab tab off the tab strip to create a new window.
4. Observed the Window outer/inner : 0x0

But Some times on opening WinSizeDebug.htm first time on chrome itself shows the output as Window outer/inner : 0x0
Hence, it seems to be very inconsistent and unable to find the bisect for this issue.

larrylaca818@ - Could you please provide any other sample file which reproduces the issue consistently. This will help us in triaging the issue better.

Thanks...!!

krajshree cmt#18, kavvaru cmt#9:
These results are consistent, but the 0x0 error only occurs on first use.
Steps should be

1. Open chrome windowed, do Not run WinSizeDebug.htm (cmt#16).
2. Create a New Tab by clicking empty right end half-tab.
3. Dragged the New Tab tab off the tab strip to create a new window (win2).
4. Run WinSizeDebug in new Window (win2.tab1), get outer : 0x0
5. Refresh win2.tab2, get outer: WxH value, 
     value is oversized +14, +7 WxH  

The 0x0 error only occurs on first use. Running WinSizeDebug in step#1, is often enough to get a non-0x0 value in step#4.

Inability to reproduce the error, depends on unknown elements of the user profile.  I see the error (in some profiles) in 59.0.3071.86 (last m59 beta, first stable m59)

Since the 0x0 error is sensitive to first use, I updated the test.htm file to access outerWidth, outerHeight multiple times(3).  Alas no change.  See attached.

outerWidth and outerHeight report values +14, +7px respectively after refresh.  See screenshots. 

For some themes, e.g. Slinky Modern:
https://chrome.google.com/webstore/detail/slinky-modern/nilnodhmmonndffbejancdeiggflcehi
the window is resized to the reported values, 
i.e. expands the window, and the values are then correct.
See screenshot slinky.

Deleted: WinSizeAlert.htm 808 bytes

WinSizeAlert.htm 808 bytes View Download

Deleted: LM56-736x385 0x0.png 21.2 KB

	LM56-736x385 0x0.png 21.2 KB View Download

Deleted: LM56-736x385.png 21.8 KB

	LM56-736x385.png 21.8 KB View Download

Deleted: LM56-736x385-slinky.png 26.8 KB

	LM56-736x385-slinky.png 26.8 KB View Download

Having a theme does not cure the 0x0 problem. Steps:
1. Open chrome windowed, start: New Tab, theme: Slinky Modern
2. Run winsize in New Tab, tab1, get 0x0

Deleted: LM56-736x385 0x0-slinky.png 22.4 KB

	LM56-736x385 0x0-slinky.png 22.4 KB View Download

I have been looking for a trivial scenario to reproduce the 0x0 error.
I have found none that is 100% repeatable.  This one hits 0x0 at least 20%

1: create a new test profile, update to show the bookmarks bar, 
1.a add a winsize bookmark for ease of testing, I don't think the bookmark impacts the error rate.  
1.b The default start page is New Tab, has thumbnails for Welcome and Webstore.  Adding other pages may improve the error rate, but I don't see a pattern.  
1.c In my environment, by default I get 4 Google Docs related extensions enabled.  I've experimented with disabling these, doesn't seem to change the error rate, but it's hard to keep the stats straight. I left them enabled, just to stay vanilla.

2: Open the test profile from a current Chrome session, using the top right name tag.  I don't think it matters how the test session is launched.  This is just for ease of use and consistency.  

3: Create 5 New Tab tabs by clicking the right half tab or CtrlT.
You not have 6 NT tabs, start on the right (tab6):
run winsize, exit the tab with the tab 'x' button.
repeat for the 5 remaining tabs (including tab1).
Usually one of the 5 added NT tabs will show 0x0,
occasionally it's the first, initial tab.

Working right to left is significant.  Working left to right may always work (non 0x0)

This scenario sees to be more consistent, at least 20% 0x0, than the tear off tab use case (create NT, drag off to create a new window) I first identified.  

For some profiles, the error rate is much higher.  Still don't know why.

Trying to reproduce the 0x0 failure is illusive.
Some profiles see it nearly all the time, other ~20%, making it hard to replicate and find the regression point.

There is another related new tab failure mode, that occurs every time, from  bug 730163  as reported earlier: 
  chrome opens near-max windowed, after last close was maximized. 
The failure use case has been simplified to use a single monitor:
1) start windowed, gen a new tab tab, tear off to spawn win2.
2) close orig win1, maximize win2, close/open from taskbar
3) new session opens windowed (last close was maximized), 
  slightly less that max, i.e. near-max

Suggest: look at  bug 730163  then revisit this one.

The javascript winsize diagnostic is 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.
Handles 0x0 best estimate bettor.
rawgit saves having to download the file locally.

Regression Testing
Beginning with 58.0.3029.19 (first m58 beta) I see the 0x0 failure:
~20% of the tear-off new tab windows report an initial outer size of 0x0
The failure persists thru canary 61.0.3140.0 (released 6/23)

Thru 57.0.2987.98 (last m57 beta == first m57 stable), the outer size is oversized, but evals without error.

These are the same regression breakpoints for  bug 730163  near-max

tkent@ - Thanks for picking this up again.  I'm still monitoring the CR activity.  

Re: bisect & reproducible usecase: See my 6/19 #10 cmt.  Outer size is always overstated, except on first use it can report 0x0.  The first use 0x0 failure is illusive.  Currently (61.0.6163.49) my main profile yields 0x0, a test profile gives the oversize value (on first use).

If someone will actively pick this CR up, I'll resurrect my notes.

I can run local regression tests back to m40, but there are profile dependencies and there was a major profile org change at m54, so testing pre M54 is tricky for me.  I only have my laptop and no VMware, so it's hard to keep the versions completely isolated.

Tried reproducing the issue on Win-10 using latest stable #60.0.3112.113 as per comment #23 but the issue seems to be very inconsistent.

Steps followed to reproduce the issue are as follows:
=====================================================
1. Created 6 new tabs by clicking the right half tab.
2. opened WinSizeAlert.htm (from comment #21) in the rightmost tab(no. 6) and got 0x0.
3. Tried bisecting to get the good and bad build range following the above process, but got inconsistent results.

larrylaca818@ - Could you please provide consistent repro steps to test the issue as inconsistent results won't help in getting bisect results.

Thanks...!!

@Kraj - Yes this one is illusive.  There are at least 3 related failures
1 0x0 size reported
2 size overstated
3 near-max reopen after maximized close

1 is illusive.  My use case was to undock/tear-off the tab just before the size check.  Still only had a 20% failure rate of getting 0x0.  See #23 for opening multiple tabs (5x), which worked for me.

2 is always overstated.  I use a screenshot, and edit with paint to get the (true) saved image size. The discrepancy is ~8-15px and constant, depending on resolution.

3 always fails.  Discrepancy like #2, see cmt#24 for use case.

1 0x0 Failure depends on something in the profile.  When it fails for me, it fails back thru M58.

Is that enuf?

FYI, this is a specific failure mode of feature improvement bug 727051

Removing the Needs-Bisect label as per C#28.