Spinoff of  http://crbug.com/758130#c6 .

When an <iframe> element becomes display:none, the LayoutIFrame is destroyed.  This tells the HTMLIFrameElement to clear its embedded content view, which calls Dispose() on the child FrameView.

  blink::LocalFrameView::Dispose()
  blink::HTMLFrameOwnerElement::SetEmbeddedContentView()
  blink::LayoutEmbeddedContent::WillBeDestroyed()
  blink::LayoutEmbeddedContent::Destroy()
  blink::LayoutObject::DestroyAndCleanupAnonymousWrappers()
  blink::Node::DetachLayoutTree()

This is bad.  The FrameView is retained by the LocalFrame object, which remains in the frame tree.  If the <iframe> is redisplayed in the future, the FrameView gets reused.

One visible consequence is that ScrollAnimator gets recreated with the wrong scroll offset.  There are probably other bugs lurking, because FrameView isn't meant to be reused after Dispose().

Even if the iframe doesn't get redisplayed, we want its FrameView to stay alive.  This is because a display:none iframe has a DOM and can run script.

Today, a display:none iframe also runs full layout.  Even though there's no LayoutIFrame for the <iframe> element, the iframe's Document holds a layout tree for the DOM inside the iframe.

After  issue 650433  (currently behind a REF named "DisplayNoneIFrameCreatesNoLayoutObject"), we will stop creating layout objects for elements inside the iframe's Document.  However, we will still create the layout object for the Document itself (LayoutView).  This REF doesn't affect FrameView lifetime considerations.

A naive fix would simply stop calling SetEmbeddedContentView(nullptr) from LayoutEmbeddedContent::WillBeDestroyed.  When I tried this, it broke some unit tests, including WebFrameSimTest.DisplayNoneIFrameHasNoLayoutObjects.  Need to investigate why.