This fails pretty reliably for me on ChromeOS 50.0.2661.87 (passed once, then failed >20 times even using a new incognito window).  Adding Needs-TestConfirmation to get some help from the QA team on understanding the scope of the change in behavior here.  Is it clearly a regression in behavior from M49 to M50?

I am seeing this issue on Latest Canary#52.0.2718.0 for Win7 as well. Let me narrow it down.

Here is the bisect info:

51.0.2665.0 - Bad
50.0.2661.87 - Good

CL:
====
https://chromium.googlesource.com/chromium/src/+log/50.0.2660.0..51.0.2667.0?pretty=fuller&n=10000

I am not able to reproduce this issue on "Chromium" builds using bisect.py.

hyunjune.kim@, could you please look into this change (https://chromium.googlesource.com/chromium/src/+/89317940af3b85bdff2f0e99c35082b5d3d517cf) if possible? Please feel free to re-assign in case if this is not related to your's.

Thank you!

@manoranjanr, I checked this issue, I guess that it is not related to my patch.
Because, need the mouse event(drag etc) to run my logic(https://chromium.googlesource.com/chromium/src/+/89317940af3b85bdff2f0e99c35082b5d3d517cf). I'll check some more. Thank you.

Given the bug description, this looks like related to layout.

Able to reproduce the issue on mac 10.11 chrome version 52.0.2723.0

Could anyone look into this please

To get action on a bug which has been assigned, and the person who owns it has disowned it, you will need to reset the bug to Untriaged. Even better, an owner who disowns should do this, particularly if the bug is only owned due to a bisect and suspicion of blame.

On Debug, occur to segmentation fault when be Twitter widget fails.
I guess that doubt DocumentLifecycle.
#0 0x000000710d7e base::debug::StackTrace::StackTrace()
#1 0x000000732def logging::LogMessage::~LogMessage()
#2 0x000002f5f929 blink::DocumentLifecycle::advanceTo()
#3 0x000002f107ea blink::Document::updateLayout()
#4 0x000002f07b45 blink::Document::updateLayoutIgnorePendingStylesheets()
#5 0x000002f10583 blink::Document::updateLayoutIgnorePendingStylesheetsForNode()
#6 0x000002f6f172 blink::Element::getBoundingClientRect()
#7 0x000003fae6eb blink::ElementV8Internal::getBoundingClientRectMethod()
#8 0x000003fa7a05 blink::ElementV8Internal::getBoundingClientRectMethodCallback()
#9 0x00000221ed5f v8::internal::FunctionCallbackArguments::Call()
#10 0x000001ce43fc v8::internal::(anonymous namespace)::HandleApiCallHelper()
#11 0x000001d1a3a7 v8::internal::Builtin_Impl_HandleApiCall()
#12 0x000001cf1f1b v8::internal::Builtin_HandleApiCall()

Did a couple of bisect runs and the all point to the following range: https://chromium.googlesource.com/chromium/src/+log/c3937b7ccbe9b8ad5afd3210831daaac5e2cb213..a7562210cff2a94205a9892b78b4a49c37afd22f

Specifically the change to turn on <link rel=preload> support by default.
Given that the page uses rel=preload and generates a console error this might indicate some sort of race condition in the preload code.

"<link rel=preload> must have a valid `as` value"

https://codereview.chromium.org/1636303003

FYI, the debug assert (which might or might not be related) is about not being able to advance to DocumentLifecycle::LayoutClean from DocumentLifecycle::VisualUpdatePending.

FWIW, even when turning off all preload support (by returning at the top of LinkLoader::loadLink, or by turning off the runtime flag), and turning off the asserts, I still see the issue.

So, it seems more likely to me that the issue is related to the ASSERT (or something else entirely) than to the preload feature.

So, removing myself as owner. I think it'd be best if someone more familiar with DocumentLifeCycle would take a look and rule out whatever's leading to the ASSERT as a possible cause.

Still able to reproduce the issue on Mac 10.11 using chrome version 52.0.2728.0

could any one please look into this issue.

Thanks, 

A friendly reminder that M51 Stable is launching soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by May 17. All changes MUST be merged into the release branch by 5pm on May 20 to make into the desktop Stable final build cut. Thanks!

This is broken in M50 so blocking M51 for it doesn't really make much sense.

Hmm. This is a pretty bad issue. Sounds like it should block something, right?

Blockers are to prevent regressions from reaching stable. This is already broken on stable so blocking another release for it won't help.

The severity is represented by the priority.

More importantly perhaps, this appears to have been fixed on tip of tree (or the page has changed) as I can no longer get it to reproduce and debug builds no longer trigger the lifecycle assert mentioned in comments 9 and 12.

Sounds good. I'll retest it.

Thanks! If it's due to a fix on the AMP side I'd be curious to learn about it, would also be good if there was a way to load the old version to fix the bug on our side.

If it's a fix on our side I'll try to track it down and see if we can down integrate it into 51.

No, it's definitely not a fix on the AMP's side. AMP only loads Twitter's `platform.js`, so we didn't try to fix it, since the issue was happening deep inside.

I just retested on a few platforms and here's what I see:

- Android prod (50.0.2661.89): Works reliably
- Mac OSX prod (50.0.2661.94): Works reliable
- Android dev  (52.0.2723.0) : Fails 100% of the time
- Mac OSX dev  (52.0.2729.0) : Works, but the sizing of the tweet is sometimes wrong (incorrect scrollHeight returned?)
- Mac OSX dev  (52.0.2729.0) + Nexus 5X emulation : Fails 100% of the time.

Given that Mac OSX dev works, but not in Nexus 5X emulation seems to indicate that it might to do with parent window's size?

Interesting, thanks for the analysis!

Also, did some testing. This is definitely a regression. Works on 50, fails in 52.

Been trying to play with the surrounding CSS to fix, but so far no luck.

Some additional data: It does not make a difference to only start drawing the widget after DOMContentLoaded or even later than that.

I figured out why this only happens on Nexus emulation for some people:

Twitter is running an experiment to replace the iframe with Shadow DOM. But they only do so for some users and they do NOT do it on Android Chrome.

Unable to repro this issue on Windows 7 & MAC (10.11.4) for Google Chrome Canary Version - 52.0.2738.0 

Screen-recording is attached.

@dvoytenko: Could you please confirm the same and update the thread accordingly.

Thank you.

Deleted: 607336.mp4 1.6 MB

607336.mp4 1.6 MB Download

@rnimmagadda Did you turn on Android-mobile emulation? Because of a Twitter experiment that is currently required to get a consistent repro.

Please remove the Restrict-View-Google.

We're cutting M51 LAST beta candidate tomorrow. Your bug is labelled as M51 Beta ReleaseBlock, pls make sure to land the fix and get it merged into the release branch before 4:00 PM PST tomorrow (Tuesday - May 17).

@rnimmagadda this has gotten a bit confusing since twitter now serves different code to desktop and mobile. Ideally this now should be tested on Android Chrome to reproduce. The issue is still there as of today.

Dimitri can you help find someone to own this?

eae@ to help find someone to investigate this further.

malteubl@ confirmed explicitly that it does not affect M51, just M52+.  Updating milestone to match.

Is there a know good M51 version? Given the reports that this failed in 50 comment 36 is surprising.

FYI, this fails to load in 50.0.2661.94 when in android emulation mode.

Finally tracked down the root cause thanks. Caused by the RenderingPipelineThrottling feature which launched in 50, got reverted in 51 and turn back on again in 52. Explaining the confusing bisect results.

When it bails out in Document::updateLayoutTree it leaves the lifecycle state as VisualUpdatePending instead of advancing or resetting it. This leaves the lifecycle in a state it cannot recover from.

Turing off RenderingPipelineThrottling fixes the problem.

Issue 612272 has been merged into this issue.

#612272 was merged into this. Both bugs have the same symptom (no Twitter widget), but this is due to different reasons

In #612272 the load event of a link tag failed to fire. Twitter was waiting on this and never rendered the widget.

In this bug, Twitter tried to measure the height of their widget (after rendering, so they got further in their lifecycle), which always returned 0, thus then setting their iframe to height 0.

AMP landed (and will ship tomorrow) a workaround for this https://github.com/ampproject/amphtml/pull/3242

I think the workaround may point to other instances where throttling iframes may not be web compatible:

AMP, if possible, tries to reuse the same JS across iframes. With that it can happen, that a JS library was loaded in a throttled iframe, but then manipulates DOM in a non-throttled iframe. The pull request turns off this optimization.

Please remove restrict-view-google. I can no longer see that label myself :(

RenderPipelineThrottling should not affect the values returned to script when measuring the sizes of elements. If that's the case, then it's not intentional.

It does by leaving the lifecycle in an inconsistent state. Unless we can fix this quickly we should turn off the feature to give us more time to fix it.

Here's a fix which makes both http://output.jsbin.com/xupizi/quiet and  http://output.jsbin.com/xeriso/quiet work: https://codereview.chromium.org/1994133002 (needs tests)

> JS library was loaded in a throttled iframe, but then manipulates DOM in a non-throttled iframe

I'm trying to write a test for my patch. Could some explain how this type of cross-iframe DOM access happens?

AMP has a "master selection" process that selects a random third party iframe and makes it available to other iframes on the same origin. This is e.g. used to do work only once that is shared across the frames.

Master selection
https://github.com/ampproject/amphtml/blob/master/3p/integration.js#L188

Commented out usage for Twitter 
https://github.com/ampproject/amphtml/blob/master/3p/twitter.js#L39

Thanks, that was exactly what I was looking for!

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

commit afdf51c967149db6bd8d6a533886efc957435e18
Author: skyostil <skyostil@chromium.org>
Date: Fri May 20 11:07:49 2016

Disallow throttling while running requestAnimationFrame callbacks

If a requestAnimationFrame callback tries to do a synchronous style
computation in another frame which is currently throttled, this fails
because throttling is allowed for the entire BeginMainFrame, which
includes running rAF callbacks as a substep.

This patch fixes the issue by disallowing throttling while executing rAF
callbacks. Note that rAF callbacks for throttled frames are still
skipped.

BUG= 607336 

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

[modify] https://crrev.com/afdf51c967149db6bd8d6a533886efc957435e18/third_party/WebKit/Source/core/dom/DocumentLifecycle.cpp
[modify] https://crrev.com/afdf51c967149db6bd8d6a533886efc957435e18/third_party/WebKit/Source/core/dom/DocumentLifecycle.h
[modify] https://crrev.com/afdf51c967149db6bd8d6a533886efc957435e18/third_party/WebKit/Source/core/page/PageAnimator.cpp
[modify] https://crrev.com/afdf51c967149db6bd8d6a533886efc957435e18/third_party/WebKit/Source/web/tests/FrameThrottlingTest.cpp

I think this missed the branch point.

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/+/6c49b69538a2b834e6e463195147ac239291672e

commit 6c49b69538a2b834e6e463195147ac239291672e
Author: Sami Kyostila <skyostil@chromium.org>
Date: Mon May 23 11:33:29 2016

Disallow throttling while running requestAnimationFrame callbacks

If a requestAnimationFrame callback tries to do a synchronous style
computation in another frame which is currently throttled, this fails
because throttling is allowed for the entire BeginMainFrame, which
includes running rAF callbacks as a substep.

This patch fixes the issue by disallowing throttling while executing rAF
callbacks. Note that rAF callbacks for throttled frames are still
skipped.

BUG= 607336 

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

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

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

[modify] https://crrev.com/6c49b69538a2b834e6e463195147ac239291672e/third_party/WebKit/Source/core/dom/DocumentLifecycle.cpp
[modify] https://crrev.com/6c49b69538a2b834e6e463195147ac239291672e/third_party/WebKit/Source/core/dom/DocumentLifecycle.h
[modify] https://crrev.com/6c49b69538a2b834e6e463195147ac239291672e/third_party/WebKit/Source/core/page/PageAnimator.cpp
[modify] https://crrev.com/6c49b69538a2b834e6e463195147ac239291672e/third_party/WebKit/Source/web/tests/FrameThrottlingTest.cpp

Looks like the current dev channel build (52.0.2743.6) should have this fix now.

Checked. It's fixed in 52.0.2743.6

Thanks for verifying!