Site in attachment is:
http://www.ehanlin.com.tw/nu_ehanlin/examine.html?year=105&subject=JPC&volume=R&version=JG&id=57ac21dce4b026a19c93606b&continue=true

peter@, what platform was this on?

And how do we get an account to reproduce the problem? Or can you reproduce it with a small test case?

This screenshot ran on window10 platform.

And I don't know how to reproduce the problem.

Because I don't know the problem's cause, it's sometime producing on the same page.

Hello,

I reproduced the problem, and I have record videos on youtube.

https://youtu.be/52ohV0JjJxc
https://youtu.be/BAtCwUwjgL0

It seems related that a previous iframe container's display to be set `none`.

The OSX platform has the problem, too. 

The user agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36" on youtube videos(52ohV0JjJxc and BAtCwUwjgL0).

Hello,

I have added a small test case:

http://test.tbbt.com.tw/nu_ehanlin/iframeRenderBug.html

The page load complete when the alert window is opened to display "All Ready".

And you will click next button to reproduce the problem.

It's possible that you need try many times.

I can't reproduce on Mac m53 or Linux m52. Passing on to the test team to see if they can repro.

Tested the issue on Windows 7, Mac 10.11.6, Ubuntu 14.04 using latest stable 52.0.2743.116, canary 54.0.2830.0, beta 53.0.2785.57 with below steps:

1.Opened URL: http://test.tbbt.com.tw/nu_ehanlin/iframeRenderBug.html
2.Clicked on OK button for 'All ready' pop up.
3.Clicked on 'next' button.
4.Question displayed with options.

Please find attached screencast and update if anything missed here in triaging the issue.

schenney@Could you please provide actual and expected behavior screencast for better understanding the issue to test from test team end.

Deleted: 637373.mp4 931 KB

	637373.mp4 931 KB View Download

I reproduced on iframeRenderBug.html(retry 3 times).

URL：https://youtu.be/FjOvyb31VRY

And I had to try altering element's content.

But it's no effect.

URL: https://youtu.be/FjOvyb31VRY?t=3m41s

Thanks very much for the video showing your reproduction.

Testers, the video in comment #10 shows the expected behavior in the first 2 loads, then the error when the content is missing for case "6". I'll try repro locally some more.

I have also reproduced. There are some interesting aspects to this:

1) The frame "src" link is to a aws server that serves a load of JS that builds the frame content.
2) All the DOM content is there, inspector can inspect it, but we are not painting it at all. Nothing I tried resulted in us painting it.
3) Switching to other "panels" in the page and then back again results in the same effect. i.e. the missing content is persistent; it's not a one-off failure to paint.
4) We are issuing paint invalidation for the area that the frame would occupy.
5) Reloading the frame (from the context menu) causes the content to appear.

From 2) it seems that we are creating and laying out the whole thing, yet we are not drawing it. For some reason we never seem to draw it, yet I haven't found any CSS reason why we would not paint it. That's consistent with us continuing to think that display is none. But modifying display in DevTools does nothing.

I'm starting to very strongly suspect that this is paint item caching related. wangxianzhu@, could you tell us how to verify that?

This seems a throttling issue. When an iframe is unexpectedly invisible, its shouldThrottleRendering() is true.

Xianzhu, what do you mean by unexpectedly invisible? That the frame is actually on-screen but thinks it's offscreen?

The frame's contents are all there in the page, as shown by inspector. We are issuing repaints, as shown by paint invalidation flashing. But the content is never drawn on the screen.

It takes a few passes through the test data to see the problem, as shown in the video. Only go forward - if it displays once per reload it displays again for that reload. If it is not displayed once, it is never displayed again until you reload the frame (or page).

I looked into this and turns out the invisible FrameViews have been disposed, and one of the side effects of disposing is cancelling the task to throttle or unthrottle the frame. What happens is that the FrameView becomes visible and gets disposed, causing the task for unthrottling the frame to get cancelled, so the frame remains throttled.

I've got a simple fix which just removes the code that cancels the throttling task -- it's not strictly needed anyway. It's still deeply weird that disposed frames end up sticking around for a long time, but I don't really know if things are supposed to work like that (+cc dcheng@ in case there's something obviously wrong here with frame lifetimes).

Yikes, sorry I missed this the first time around!

skyostil@, did you ever land the simple fix? I can't repro on ToT at the moment. What you're describing sounds like something is very broken in Blink though: a FrameView should only be disposed if the current Document in the LocalFrame is being shutdown().

ASAN didn't like my fix and it was probably a bad idea anyway. Let me try to repro this again on ToT and grab a stack trace of how the frame is getting disposed.

Definitely repros on M53 Beta if you load http://test.tbbt.com.tw/nu_ehanlin/iframeRenderBug.html a couple of times and flip through each card.

So yeah this seems to be still happening on ToT. What I'm seeing is we're doing things like lifecycle updates and hit testing against disposed FrameViews. For example:

Lifecycle update for disposed FrameView 0x7becf1c4a18:
#0 0x7fdb582d0f7e base::debug::StackTrace::StackTrace()
#1 0x7fdb4b658100 blink::FrameView::updateViewportIntersectionsForSubtree()
#2 0x7fdb4b6580c5 blink::FrameView::updateViewportIntersectionsForSubtree()
#3 0x7fdb4b657b84 blink::FrameView::updateLifecyclePhasesInternal()
#4 0x7fdb4b9ed4ea blink::PageAnimator::updateAllLifecyclePhases()
#5 0x7fdb52ee7dcd blink::WebViewImpl::updateAllLifecyclePhases()
#6 0x7fdb55048974 cc::ProxyMain::BeginMainFrame()
#7 0x7fdb55053760 _ZN4base8internal7InvokerINS0_9BindStateIMN2cc9ProxyMainEFvSt10unique_ptrINS3_28BeginMainFrameAndCommitStateESt14default_deleteIS6_EEEJNS_7WeakPtrIS4_EENS0_13PassedWrapperIS9_EEEEEFvvEE7RunImplIRKSB_RKSt5tupleIJSD_SF_EEJLm0ELm1EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
#8 0x7fdb582d1a91 base::debug::TaskAnnotator::RunTask()
#9 0x7fdb53159168 blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#10 0x7fdb53157f3c blink::scheduler::TaskQueueManager::DoWork()
#11 0x7fdb582d1a91 base::debug::TaskAnnotator::RunTask()
#12 0x7fdb582f340c base::MessageLoop::RunTask()
#13 0x7fdb582f3718 base::MessageLoop::DeferOrRunPendingTask()
#14 0x7fdb582f3adb base::MessageLoop::DoWork()
#15 0x7fdb582f4bda base::MessagePumpDefault::Run()
#16 0x7fdb583169be base::RunLoop::Run()
#17 0x7fdb5631608b content::RendererMain()
#18 0x7fdb563deb41 content::RunZygote()
#19 0x7fdb563dfbf4 content::ContentMainRunnerImpl::Run()
#20 0x7fdb563de710 content::ContentMain()
#21 0x7fdb588ee93d ChromeMain

FrameView 0x7becf1c4a18 was disposed at:
#0 0x7fdb582d0f7e base::debug::StackTrace::StackTrace()
#1 0x7fdb4b64e92f blink::FrameView::dispose()
#2 0x7fdb4b6d374c blink::HTMLFrameOwnerElement::UpdateSuspendScope::performDeferredWidgetTreeOperations()
#3 0x7fdb4b6d39c1 blink::HTMLFrameOwnerElement::UpdateSuspendScope::~UpdateSuspendScope()
#4 0x7fdb4b4bd267 blink::Document::updateStyle()
#5 0x7fdb4b4b9fe4 blink::Document::updateStyleAndLayoutTree()
#6 0x7fdb4b4bd7d6 blink::Document::updateStyleAndLayout()
#7 0x7fdb4b4bd7c9 blink::Document::updateStyleAndLayout()
#8 0x7fdb4b4bd735 blink::Document::updateStyleAndLayoutIgnorePendingStylesheets()
#9 0x7fdb52ed04b0 blink::WebNode::isFocusable()
#10 0x7fdb599c4baa autofill::form_util::WebFormControlElementToFormField()
#11 0x7fdb599c5827 autofill::form_util::(anonymous namespace)::FormOrFieldsetsToFormData()
#12 0x7fdb599c6e1b autofill::form_util::(anonymous namespace)::UnownedFormElementsAndFieldSetsToFormData()
#13 0x7fdb599db6ec autofill::CreatePasswordFormFromUnownedInputElements()
#14 0x7fdb599d3079 autofill::PasswordAutofillAgent::SendPasswordForms()
#15 0x7fdb599c2622 autofill::AutofillAgent::didAssociateFormControlsDynamically()
#16 0x7fdb5305a9b9 blink::TimerBase::runInternal()
#17 0x7fdb582d1a91 base::debug::TaskAnnotator::RunTask()
#18 0x7fdb53159168 blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#19 0x7fdb53157f3c blink::scheduler::TaskQueueManager::DoWork()
#20 0x7fdb582d1a91 base::debug::TaskAnnotator::RunTask()
#21 0x7fdb582f340c base::MessageLoop::RunTask()
#22 0x7fdb582f3718 base::MessageLoop::DeferOrRunPendingTask()
#23 0x7fdb582f3adb base::MessageLoop::DoWork()
#24 0x7fdb582f4bda base::MessagePumpDefault::Run()
#25 0x7fdb583169be base::RunLoop::Run()

----------------------------------------------------------------------------------------

Hit testing example:

Lifecycle update for disposed FrameView 0x7becf2ab7c0:
#0 0x7fdb582d0f7e base::debug::StackTrace::StackTrace()
#1 0x7fdb4b658100 blink::FrameView::updateViewportIntersectionsForSubtree()
#2 0x7fdb4b6580c5 blink::FrameView::updateViewportIntersectionsForSubtree()
#3 0x7fdb4b6580c5 blink::FrameView::updateViewportIntersectionsForSubtree()
#4 0x7fdb4b657b84 blink::FrameView::updateLifecyclePhasesInternal()
#5 0x7fdb4b92ee39 blink::LayoutView::hitTest()
#6 0x7fdb4b4c2420 blink::Document::performMouseEventHitTest()
#7 0x7fdb4b7dbe4c blink::EventHandlingUtil::performMouseEventHitTest()
#8 0x7fdb4b7d73b8 blink::EventHandler::handleMouseMoveOrLeaveEvent()
#9 0x7fdb4b7d7050 blink::EventHandler::handleMouseMoveEvent()
#10 0x7fdb4b7de37a blink::MouseEventManager::fakeMouseMoveEventTimerFired()
#11 0x7fdb5305a9b9 blink::TimerBase::runInternal()
#12 0x7fdb582d1a91 base::debug::TaskAnnotator::RunTask()
#13 0x7fdb53159168 blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#14 0x7fdb53157f3c blink::scheduler::TaskQueueManager::DoWork()
#15 0x7fdb582d1a91 base::debug::TaskAnnotator::RunTask()
#16 0x7fdb582f340c base::MessageLoop::RunTask()
#17 0x7fdb582f3718 base::MessageLoop::DeferOrRunPendingTask()
#18 0x7fdb582f3adb base::MessageLoop::DoWork()
#19 0x7fdb582f4bda base::MessagePumpDefault::Run()
#20 0x7fdb583169be base::RunLoop::Run()
#21 0x7fdb5631608b content::RendererMain()
#22 0x7fdb563deb41 content::RunZygote()
#23 0x7fdb563dfbf4 content::ContentMainRunnerImpl::Run()
#24 0x7fdb563de710 content::ContentMain()
#25 0x7fdb588ee93d ChromeMain
#26 0x7fdb4f8acf45 __libc_start_main
#27 0x7fdb588ee819 <unknown>

FrameView 0x7becf2ab7c0 disposed was at:
#0 0x7fdb582d0f7e base::debug::StackTrace::StackTrace()
#1 0x7fdb4b64e92f blink::FrameView::dispose()
#2 0x7fdb4b6d374c blink::HTMLFrameOwnerElement::UpdateSuspendScope::performDeferredWidgetTreeOperations()
#3 0x7fdb4b6d39c1 blink::HTMLFrameOwnerElement::UpdateSuspendScope::~UpdateSuspendScope()
#4 0x7fdb4b4bd267 blink::Document::updateStyle()
#5 0x7fdb4b4b9fe4 blink::Document::updateStyleAndLayoutTree()
#6 0x7fdb4b3ad1fa blink::CSSComputedStyleDeclaration::getPropertyCSSValue()
#7 0x7fdb4b3adac1 blink::CSSComputedStyleDeclaration::getPropertyValue()
#8 0x7fdb4bb6d853 blink::CSSStyleDeclarationV8Internal::getPropertyValueMethodCallback()
#9 0x7fdb542d62a4 v8::internal::FunctionCallbackArguments::Call()
#10 0x7fdb543584ad v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
#11 0x7fdb543579b5 v8::internal::Builtin_Impl_HandleApiCall()

Also looks like the same FrameView can be disposed multiple times, but maybe that's safe?

Another tentative fix: https://codereview.chromium.org/2415013002/

Looks like the rewrite to make frame throttling use IntersectionObserver (https://codereview.chromium.org/2272773002/) makes this bug go away. I don't really understand why or how, but I'm not seeing any of the disposed FrameViews after that patch anymore.

Marking fixed now that https://codereview.chromium.org/2272773002/ landed.

Sorry, Devs, but this issue is still happening, Mac and PC chrome Version 57.0.2987.98, and in my case it is TinyMCE content not appearing.

At first I thought it might be because the iframe was embedded 3 frames deep (I use TinyMCE in other places in my app that still works). But I changed my layout so the iframe was only 2 frames deep (like the places it does work), but it still wasn't painted. I still had the content that was 3 deep still on the page, so I tried it for fun, AND THE CONTENT APPEARED. If I commented out the new code that was 2 deep (but wasn't working), then the painting issue returned. 

So I made the new code not visible on the page, and the old code still worked. I would have been happy with that, but after uploading to my live server, NEITHER CODE WORKED! It worked on my local server only; except I fiddled a bit more then it wouldn't work locally at all.

The funny thing is that my code worked fine up until around January 2017, then it stopped working for me, and all my coworkers who use these tools. This issue goes back many years, but never affected me until after the bugs have been claimed as "fixed" here. Very weird and frustrating.

Any thoughts?

Thanks

Deleted: 2017-03-21 13_02_40-iframe not painted.png 209 KB

	2017-03-21 13_02_40-iframe not painted.png 209 KB View Download

Could you do one more thing for me, and check that DevTools is not reporting any aborted loads in the network tab? We've had issues with images not appearing due to canceled loads, and maybe this is the same thing, particularly as it appears to be server dependent.

Schenney,

Nothing aborted or errors in JS. To add to the confusion, I got a Chrome update to 57.0.2987.110 this afternoon, relaunched the browser, and my local server version is working again (the old html, with the hidden new html), but still my online site does not. Sigh. Everything is still served via http from the same domain, so it shouldn't a security thing - or is it?

I'm getting the content thru ajax, and using the TinyMCE code to load it etc. I've been using this setup for almost a decade, no problems until January.

Thanks!

Deleted: 2017-03-21 16_19_18-network tab.png 78.9 KB

	2017-03-21 16_19_18-network tab.png 78.9 KB View Download

Bug should be re-opened: 
Since fix was applied, I have this problem manifest in a consistent manner on a nested iframe of one of my apps. A screencast can be found here: http://screencast-o-matic.com/watch/cbfDhHXfL3

- There are no warnings in console
- elements appear correctly in DOM
- Inspecting elements in inspector indicates they are located correctly - in the "white" area
they just do not appear on screen

This happens from chrome 57 on both windows (7 & 10) and Mac.

(I am sorry I do not have a trivial example. To see this on your own machine you will have to install the extension. I will supply details if that is acceptable)

Comment 27: I notice that you mention an extension, which means it's possible it could be an out-of-process iframe.  (Then again, if you can see the elements of the iframe in DevTools, it's probably not.)  Can you check your Chrome Task Manager to see if there's a "Subframe" process when the bug is happening?  If so, please file a separate bug and let us know what the bug number is.

Opened new  issue 712320 

Comment 29: Thanks!  Following up there, since it looks like that has a good chance of being a different bug.

Hello,

I think we are still facing the same bug in Chrome 58.0.3029.81 (64-bit) on Linux. Please check the video (https://drive.google.com/file/d/0ByG9lmw9sRzbZzkxb2hEbnBXdGM/view?usp=sharing) for details (it is better to download it, as a preview has a very bad quality).

Credentials for test account on surfly.com:
email: yauhen+chrome@surfly.com
password: chrometest

To reproduce it you need to start a session with test url http://dev.sascargo.com/en/Environment/TestCobrowseAPI.aspx and join the session with Chrome browser. Please also enable "Disable cache" option in developer toolbars.

I also noticed that on the test page (http://dev.sascargo.com/en/Environment/TestCobrowseAPI.aspx) inside the <head> element there is a <link> element:

<link rel="stylesheet" href="/styles/StyleCollection.css" type="text/css">

The content of the file is the following:
@import url("BasicDesign.css");
@import url("HeaderDesign.css");
@import url("NavigationDesign.css");
@import url("FooterDesign.css");
@import url("TextDesign.css");
@import url("SubMenuDesign.css");
@import url("ContentDesign.css");
@import url("Common.css");
@import url("StationFileStyle.css");
@import url("Components/ImageList.css");
@import url("Skins/SasCargo/Grid.SasCargo.css");
@import url("Skins/SasCargo/Calendar.SasCargo.css");
@import url("Skins/SasCargo/ComboBox.SasCargo.css");
@import url("Skins/SasCargo/ToolTip.SasCargo.css");
@import url("Skins/SasCargo/Editor.SasCargo.css");
@import url("Skins/SasCargo/Menu.SasCargo.css");

If I move imports out of the css file directly into the <style> element like this:
<style type="text/css">
@import url("/styles/BasicDesign.css");
@import url("/styles/HeaderDesign.css");
@import url("/styles/NavigationDesign.css");
@import url("/styles/FooterDesign.css");
@import url("/styles/TextDesign.css");
@import url("/styles/SubMenuDesign.css");
@import url("/styles/ContentDesign.css");
@import url("/styles/Common.css");
@import url("/styles/StationFileStyle.css");
@import url("/styles/Components/ImageList.css");
@import url("/styles/Skins/SasCargo/Grid.SasCargo.css");
@import url("/styles/Skins/SasCargo/Calendar.SasCargo.css");
@import url("/styles/Skins/SasCargo/ComboBox.SasCargo.css");
@import url("/styles/Skins/SasCargo/ToolTip.SasCargo.css");
@import url("/styles/Skins/SasCargo/Editor.SasCargo.css");
@import url("/styles/Skins/SasCargo/Menu.SasCargo.css");
</style>

there is no rendering issues.

The website renders properly in all other browsers.

Video: https://drive.google.com/file/d/0ByG9lmw9sRzbZzkxb2hEbnBXdGM/view?usp=sharing

Please post new information on https://bugs.chromium.org/p/chromium/issues/detail?id=712320

I have linked back to the previous comment but activity on Fixed bugs is not always examined.

Thanks! Will do!

The new issue (https://bugs.chromium.org/p/chromium/issues/detail?id=718358) is created from the comment #31