Adding RB label as this is recent regression.

Assigning back to the reporter since this looks unrelated to the mentioned r396823.

+dmazzoni

This looks like a sideeffect of the fix for bug  http://crbug.com/613336 

The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/a7e78f6f5d453c52313b74de10c5f680aa3d5ee3

commit a7e78f6f5d453c52313b74de10c5f680aa3d5ee3
Author: dmazzoni 
Date: Tue May 24 18:43:04 2016

Ensure LegacyRenderWidgetHostHWND is always created.

Previously, LegacyRenderWidgetHostHWND was only created inside
RenderWidgetHostViewAura::InternalSetBounds, and only if the parent
HWND was known. However, under some circumstances, InternalSetBounds
only gets called once and it gets called *before* the aura Window is
attached, so the legacy win never gets created.

Fix it by also trying to create the legacy win in
RWHVA::AddedToRootWindow().

BUG= 613336 

Review-Url: https://codereview.chromium.org/1996163002
Cr-Commit-Position: refs/heads/master@{#395649}

I'm seeing this locally too on "Version 53.0.2754.0 canary", related to creating a new tab, but I'm not sure of an exact repro.

Thanks. I'll look into this. Repro steps would be welcome, I haven't seen this myself but I'll try.

Since this morning I hit this bug almost 3 times not sure which steps are landing me in this state :

First time  : Very first time I had no clue, since I was trying to open a folder on my desktop and wasn't able to hence restarted my machine and later everything worked.

Second time : little improved and was able to identify that this is Chrome Canary which is causing this and killed the browser from taskmanager.

Third time : Updating this bug, will try to exit Canary.


Note : Just curious to know why this wasn't a dev blocker(sure there are no solid repro steps), but the experience after we hit this bug is not pleasant given today we are releasing first M53 dev.

As per my offline chat with ananta@ and suggested us to block dev due to this issue, Also informed that the fix is not straight easy. 
hence marking the bug as release-block-dev for M53.

The bug typically reproduces when you open a pdf file in chrome or print in chrome and then switch to a new tab or another tab in that window.

Does not make chrome unusable in my opinion. Just an annoying button shows up on the taskbar which does not go away until the tab with the pdf or the print preview is closed.

I've had it happen that the window somehow disappears and it seems like no events get sent through to the real window.

patch here https://codereview.chromium.org/2031213002/

Because Chrome is usable, I am not going to block the dev channel.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b35c046639c244df4a954a791e24cfe7d5270daa

commit b35c046639c244df4a954a791e24cfe7d5270daa
Author: ananta <ananta@chromium.org>
Date: Fri Jun 03 20:20:24 2016

Fix a bug with the Chrome legacy window at times becoming a top level window with a non functional button in the taskbar.

This bug typically occurs if the legacy window stays around after it is
removed from the original root window.

It looks like a recent change (https://codereview.chromium.org/1996163002)
which ensures that the legacy window is always created exacerbates this
problem by creating the legacy windows early and some of them stay around
after a tab switch. Typical cases include opening a pdf file in chrome
which causes at least two RWVHA instances to be active at any given point
and the legacy window which belongs to the original instance becomes a
button on the taskbar when the tab is switched.

Fix is to never reparent to the desktop window and instead always reparent
to the hidden window.

BUG= 616410 

Review-Url: https://codereview.chromium.org/2031213002
Cr-Commit-Position: refs/heads/master@{#397790}

[modify] https://crrev.com/b35c046639c244df4a954a791e24cfe7d5270daa/content/browser/renderer_host/legacy_render_widget_host_win.cc
[modify] https://crrev.com/b35c046639c244df4a954a791e24cfe7d5270daa/content/browser/renderer_host/render_widget_host_view_aura.cc

Just to update,
Rechecked above issue on build no. 53.0.2761.2, it appears to be fixed and working as intended. Thank you!

Thanks for verifying the fix!

We need to merge this fix to M52 too, since  bug 613336  (which made this bug appear more often) was merged to M52.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

Dominic. could you please merge the CL to M52 branch,the bug is fixed as per #15.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2529de3d35849bb1e6a4d9b8ec80ca41c9004f3d

commit 2529de3d35849bb1e6a4d9b8ec80ca41c9004f3d
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Tue Jun 07 23:35:30 2016

Merge to M52: Fix a bug with the Chrome legacy window at times becoming a top level window with a non functional button in the taskbar.

This bug typically occurs if the legacy window stays around after it is
removed from the original root window.

It looks like a recent change (https://codereview.chromium.org/1996163002)
which ensures that the legacy window is always created exacerbates this
problem by creating the legacy windows early and some of them stay around
after a tab switch. Typical cases include opening a pdf file in chrome
which causes at least two RWVHA instances to be active at any given point
and the legacy window which belongs to the original instance becomes a
button on the taskbar when the tab is switched.

Fix is to never reparent to the desktop window and instead always reparent
to the hidden window.

BUG= 616410 

Review-Url: https://codereview.chromium.org/2031213002
Cr-Commit-Position: refs/heads/master@{#397790}
(cherry picked from commit b35c046639c244df4a954a791e24cfe7d5270daa)

Review URL: https://codereview.chromium.org/2040333002 .

Cr-Commit-Position: refs/branch-heads/2743@{#270}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/2529de3d35849bb1e6a4d9b8ec80ca41c9004f3d/content/browser/renderer_host/legacy_render_widget_host_win.cc
[modify] https://crrev.com/2529de3d35849bb1e6a4d9b8ec80ca41c9004f3d/content/browser/renderer_host/render_widget_host_view_aura.cc

Tested the same on win8.1 chrome version 52.0.2743.33 as per the repro in comment #10 - 
Opened a pdf document switched to new tab and giving a Ctrl+P and switching to new tab - observed no legacy window

As per the steps in the issue also could not see any legacy window opening on switching to NTP

Adding TE-Verified labels

 Issue 618980  has been merged into this issue.

Issue is resolved

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2529de3d35849bb1e6a4d9b8ec80ca41c9004f3d

commit 2529de3d35849bb1e6a4d9b8ec80ca41c9004f3d
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Tue Jun 07 23:35:30 2016

Merge to M52: Fix a bug with the Chrome legacy window at times becoming a top level window with a non functional button in the taskbar.

This bug typically occurs if the legacy window stays around after it is
removed from the original root window.

It looks like a recent change (https://codereview.chromium.org/1996163002)
which ensures that the legacy window is always created exacerbates this
problem by creating the legacy windows early and some of them stay around
after a tab switch. Typical cases include opening a pdf file in chrome
which causes at least two RWVHA instances to be active at any given point
and the legacy window which belongs to the original instance becomes a
button on the taskbar when the tab is switched.

Fix is to never reparent to the desktop window and instead always reparent
to the hidden window.

BUG= 616410 

Review-Url: https://codereview.chromium.org/2031213002
Cr-Commit-Position: refs/heads/master@{#397790}
(cherry picked from commit b35c046639c244df4a954a791e24cfe7d5270daa)

Review URL: https://codereview.chromium.org/2040333002 .

Cr-Commit-Position: refs/branch-heads/2743@{#270}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/2529de3d35849bb1e6a4d9b8ec80ca41c9004f3d/content/browser/renderer_host/legacy_render_widget_host_win.cc
[modify] https://crrev.com/2529de3d35849bb1e6a4d9b8ec80ca41c9004f3d/content/browser/renderer_host/render_widget_host_view_aura.cc