Precondition: Enable 'Material design in the browser's top chrome' by selecting 'Material' option.

Good build: 50.0.2660.0
Bad Build: 51.0.2662.0

Narrow Bisect:
https://chromium.googlesource.com/chromium/src/+log/ffa3929a4e0ae37070c41abac63406efc0ffe5ae..4acbec91b57f31a501264906aded632cc64c9300?pretty=fuller&n=100

Suspecting: r378075

Could you please help me to reassign this issue,if your change is not cause for it? 

adding RB-label, please change if required

not the right CL

This also affects the chrome:extensions page on Chrome OS as well.

Also affects chrome://settings and chrome://help pages on Linux.

Bisect suggests that the first breaking change is r384293 (https://codereview.chromium.org/1845223002). skyostil@, can you please take a look. Probably related to the navigation pane being an iframe for chrome://uber-frame/.

Looking...

All the pages here have an iframe for the menu which they keep aligned to the left side of the page by updating a "transform: translateX()" property.

When the page scale is reset after scrolling the menu offscreen, the script ultimately sets "transform: translateX(0px)". This schedules a layout, but for some reason this never ends up setting FrameView::needsLayout() on the root frame, so we never run the layout to figure out that the menu is now back on the screen and should be unthrottled.

I can make everything work by making sure the layout isn't skipped, i.e.:

 bool FrameView::layoutPending() const
 {
     // FIXME: This should check Document::lifecycle instead.
-    return m_hasPendingLayout;
+    return m_hasPendingLayout || lifecycle().state() < DocumentLifecycle::LayoutClean;
 }

but I'm not really sure if this is right fix and what the relationship between the Document's lifecycle and the FrameView's layout pending bit is supposed to be. Elliott, Xianzhu, any ideas?

Your experimental change seems to make we always layout all FrameViews in a lifecycle update if there is any pending visual update. I'm not sure if we desire this.

Also I don't understand the FIXME in FrameView::layoutPending(). If it's based on lifecycle, why do we need to check it? It seems just equivalent to calling FrameView::layout() unconditionally.

What's the exact code executed about your mentioned "This schedules a layout"?

This is not an issue with any of the MD WebUI pages, so removing Proj-MaterialDesign-WebUI. Add Proj-MaterialDesign-NativeUI if it is an issue with the MD top-Chrome.

Agreed, that doesn't seem like the right fix.

The code that triggers the style change is this:

  navFrame.style.webkitTransform = 'translateX(' + -scrollOffset + 'px)';

but I think I realized the error in my thinking: that change doesn't actually need to result in a layout since it only changes the transform on a layer. The bug is that changing the transform doesn't result in the FrameView in updating the frame rects of its widgets.

Here's a what I think is a better fix: https://codereview.chromium.org/1884603004

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

commit 0265532ea6ef8cfdccbe411647bbdb2b4e7c07c8
Author: skyostil <skyostil@chromium.org>
Date: Thu Apr 14 09:32:50 2016

Update widget geometries when transforming a layer

Previously widget geometries were only updated during actual layouts.
However if only the transform of a layer is changed, this doesn't cause
a layout and can result in stale widget geometries. In the linked bug
this causes a FrameView to remain throttled even though its transform
was changed to make the FrameView visible again.

BUG= 601353 

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

Cr-Commit-Position: refs/heads/master@{#387271}

[modify] https://crrev.com/0265532ea6ef8cfdccbe411647bbdb2b4e7c07c8/third_party/WebKit/Source/core/paint/PaintLayer.cpp
[modify] https://crrev.com/0265532ea6ef8cfdccbe411647bbdb2b4e7c07c8/third_party/WebKit/Source/web/tests/FrameThrottlingTest.cpp

Requesting a merge to M51.

Your change meets the bar and is auto-approved for M51 (branch: 2704)

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

commit 782ddcd39bb723f7d496b1791967c47ff7d74572
Author: Sami Kyostila <skyostil@chromium.org>
Date: Fri Apr 15 13:07:56 2016

Update widget geometries when transforming a layer

Previously widget geometries were only updated during actual layouts.
However if only the transform of a layer is changed, this doesn't cause
a layout and can result in stale widget geometries. In the linked bug
this causes a FrameView to remain throttled even though its transform
was changed to make the FrameView visible again.

BUG= 601353 

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

Cr-Commit-Position: refs/heads/master@{#387271}
(cherry picked from commit 0265532ea6ef8cfdccbe411647bbdb2b4e7c07c8)

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

Cr-Commit-Position: refs/branch-heads/2704@{#70}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/782ddcd39bb723f7d496b1791967c47ff7d74572/third_party/WebKit/Source/core/paint/PaintLayer.cpp
[modify] https://crrev.com/782ddcd39bb723f7d496b1791967c47ff7d74572/third_party/WebKit/Source/web/tests/FrameThrottlingTest.cpp

Retested the above issue on All-OS(Windows 7, Mac 10.11.4 & Ubuntu 14.04) with chrome version '51.0.2704.19' and unable to reproduce the above issue, tab list doesn't disappear. Hence marking the same as TE-Verified-51.0.2704.19