> swapped out Renderview

swapped out RenderView's RenderWidget's LayerTreeView.

RenderWidget::StartCompositor() should not happen for a RenderWidget that is born swapped out. If they switch to swapped out then it should do the opposite.

Note that a swapped-out RenderView may become swapped in later if the main frame navigates remote-to-local, so presumably we'll also need to restart the compositor if that happens.

I figured this out by accident while trying to understand how RenderWidget::Close() works. So patch here: https://chromium-review.googlesource.com/c/chromium/src/+/1290140

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

commit 1c6f831f14152cf4ca9e23563757d61524487234
Author: danakj <danakj@chromium.org>
Date: Wed Oct 24 17:52:26 2018

Don't SetVisible on swapped out RenderWidgets, and drop gpu resources.

When a RenderWidget is created for a RenderViewImpl, it may be
considered "swapped out". This means the main frame for this
RenderView's frame tree is not local, the RenderView exists to
hold some other local subframe, which will be composited and have
a RenderWidget. Thus the RenderWidget attached to the RenderViewImpl
is not actually used, there is no output from the remote main frame
in this tree. I like to refer to these swapped out RenderWidgets as
zombies.

During navigations, a RenderViewImpl's main frame may change to or
from being local, in which case the RenderWidget attached to it changes
to or from being a zombie.

When becoming a zombie, the WebFrameWidget attached to the
RenderViewImpl (wrapping the WebViewImpl) is destroyed, and this
marks the compositor as SetVisible(false) on the RenderWidget
(via the WebViewImpl).

When becoming alive again, a new WebFrameWidget is attached to the
RenderViewImpl, and the WebFrameWidget marks the compositor as
SetVisible(true) on the RenderWidget (via the WebViewImpl).

While a zombie, the WebViewImpl is also told not to allow any
visibility changes to be passed along to the RenderWidget. This is
because as the local subframe becomes visible with the Page, we'd
tell the WebView about this, to tell the Page. But since the
WebView now has a zombie RenderWidget, it shouldn't also tell that.

Note when the RenderViewImpl is created and initially swapped out
it creates a RenderWidget but nothing tells its compositor about the
zombie state of affairs, so it becomes visible, which makes it
acquire a Gpu channel and start its scheduler etc. Woops.

This CL rearranges things a bit.
- A new RenderWidget does not SetVisible(true) if swapped out.
- RenderViewImpl directly marks it SetVisible(false) when removing the
WebFrameWidget.
- RenderViewImpl *also* removes the LayerTreeFrameSink to drop the
Gpu channel since we don't need to be fast at becoming visible (the
RenderWidget is a zombie!)
- RenderViewImpl directly marks it as SetVisible(true) when getting
a new WebFrameWidget as the RenderWidget stops being a zombie.
- WebViewImpl stops calling SetVisible on the RenderWidget when its
main frame is not visible. In the future the RenderWidget should be
a member of the main LocalFrame, and thus won't even exist when the
main frame is not local.

R=dcheng@chromium.org, piman@chromium.org

Change-Id: I87a5d0dfeaaf08cb91c9348b26b4205db55b3a81
Bug:  894899 , 419087
Reviewed-on: https://chromium-review.googlesource.com/c/1290140
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602389}
[modify] https://crrev.com/1c6f831f14152cf4ca9e23563757d61524487234/content/renderer/gpu/layer_tree_view.cc
[modify] https://crrev.com/1c6f831f14152cf4ca9e23563757d61524487234/content/renderer/gpu/layer_tree_view.h
[modify] https://crrev.com/1c6f831f14152cf4ca9e23563757d61524487234/content/renderer/render_view_impl.cc
[modify] https://crrev.com/1c6f831f14152cf4ca9e23563757d61524487234/content/renderer/render_widget.cc
[modify] https://crrev.com/1c6f831f14152cf4ca9e23563757d61524487234/content/renderer/render_widget.h
[modify] https://crrev.com/1c6f831f14152cf4ca9e23563757d61524487234/third_party/blink/renderer/core/exported/web_view_impl.cc
[modify] https://crrev.com/1c6f831f14152cf4ca9e23563757d61524487234/third_party/blink/renderer/core/exported/web_view_impl.h
[modify] https://crrev.com/1c6f831f14152cf4ca9e23563757d61524487234/third_party/blink/renderer/core/frame/web_view_frame_widget.cc

This is mostly better. headless_browsertests are still making a main frame for a swapped out renderwidget for some reason ??

[1024/123342.866447:ERROR:render_widget.cc(426)] 0x1ed036ecc400 new RenderWidget swapped out 1
[1024/123342.876458:ERROR:render_widget.cc(2892)] 0x1ed036ecc400 StartCompositor
#0 0x7f93886cbf3f base::debug::StackTrace::StackTrace()
#1 0x7f93853cfa54 content::RenderWidget::StartCompositor()
#2 0x7f93853c0f5c content::RenderViewImpl::AttachWebFrameWidget()
#3 0x7f9385370a5b content::RenderFrameImpl::CreateFrame()
#4 0x7f93853b3d52 content::RenderThreadImpl::CreateFrame()
#5 0x7f93845fcb93 content::mojom::RendererStubDispatch::Accept()
#6 0x7f93838aa892 mojo::InterfaceEndpointClient::HandleValidatedMessage()

Which causes a DCHECK to crash in future work that verifies no compositors for swapped out widgets.

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

commit e6901925dd5b37d55accbac55564f639bf4f788a
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Wed Oct 24 20:11:12 2018

Revert "Don't SetVisible on swapped out RenderWidgets, and drop gpu resources."

This reverts commit 1c6f831f14152cf4ca9e23563757d61524487234.

Reason for revert: Revert due to FindIt analysis.

Original change's description:
> Don't SetVisible on swapped out RenderWidgets, and drop gpu resources.
> 
> When a RenderWidget is created for a RenderViewImpl, it may be
> considered "swapped out". This means the main frame for this
> RenderView's frame tree is not local, the RenderView exists to
> hold some other local subframe, which will be composited and have
> a RenderWidget. Thus the RenderWidget attached to the RenderViewImpl
> is not actually used, there is no output from the remote main frame
> in this tree. I like to refer to these swapped out RenderWidgets as
> zombies.
> 
> During navigations, a RenderViewImpl's main frame may change to or
> from being local, in which case the RenderWidget attached to it changes
> to or from being a zombie.
> 
> When becoming a zombie, the WebFrameWidget attached to the
> RenderViewImpl (wrapping the WebViewImpl) is destroyed, and this
> marks the compositor as SetVisible(false) on the RenderWidget
> (via the WebViewImpl).
> 
> When becoming alive again, a new WebFrameWidget is attached to the
> RenderViewImpl, and the WebFrameWidget marks the compositor as
> SetVisible(true) on the RenderWidget (via the WebViewImpl).
> 
> While a zombie, the WebViewImpl is also told not to allow any
> visibility changes to be passed along to the RenderWidget. This is
> because as the local subframe becomes visible with the Page, we'd
> tell the WebView about this, to tell the Page. But since the
> WebView now has a zombie RenderWidget, it shouldn't also tell that.
> 
> Note when the RenderViewImpl is created and initially swapped out
> it creates a RenderWidget but nothing tells its compositor about the
> zombie state of affairs, so it becomes visible, which makes it
> acquire a Gpu channel and start its scheduler etc. Woops.
> 
> This CL rearranges things a bit.
> - A new RenderWidget does not SetVisible(true) if swapped out.
> - RenderViewImpl directly marks it SetVisible(false) when removing the
> WebFrameWidget.
> - RenderViewImpl *also* removes the LayerTreeFrameSink to drop the
> Gpu channel since we don't need to be fast at becoming visible (the
> RenderWidget is a zombie!)
> - RenderViewImpl directly marks it as SetVisible(true) when getting
> a new WebFrameWidget as the RenderWidget stops being a zombie.
> - WebViewImpl stops calling SetVisible on the RenderWidget when its
> main frame is not visible. In the future the RenderWidget should be
> a member of the main LocalFrame, and thus won't even exist when the
> main frame is not local.
> 
> R=​dcheng@chromium.org, piman@chromium.org
> 
> Change-Id: I87a5d0dfeaaf08cb91c9348b26b4205db55b3a81
> Bug:  894899 , 419087
> Reviewed-on: https://chromium-review.googlesource.com/c/1290140
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Antoine Labour <piman@chromium.org>
> Commit-Queue: danakj <danakj@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#602389}

TBR=danakj@chromium.org,dcheng@chromium.org,piman@chromium.org

Change-Id: I2ec1cc5c7bfa723f4fafea7efe01d38ae5019532
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  894899 , 419087
Reviewed-on: https://chromium-review.googlesource.com/c/1298330
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602428}
[modify] https://crrev.com/e6901925dd5b37d55accbac55564f639bf4f788a/content/renderer/gpu/layer_tree_view.cc
[modify] https://crrev.com/e6901925dd5b37d55accbac55564f639bf4f788a/content/renderer/gpu/layer_tree_view.h
[modify] https://crrev.com/e6901925dd5b37d55accbac55564f639bf4f788a/content/renderer/render_view_impl.cc
[modify] https://crrev.com/e6901925dd5b37d55accbac55564f639bf4f788a/content/renderer/render_widget.cc
[modify] https://crrev.com/e6901925dd5b37d55accbac55564f639bf4f788a/content/renderer/render_widget.h
[modify] https://crrev.com/e6901925dd5b37d55accbac55564f639bf4f788a/third_party/blink/renderer/core/exported/web_view_impl.cc
[modify] https://crrev.com/e6901925dd5b37d55accbac55564f639bf4f788a/third_party/blink/renderer/core/exported/web_view_impl.h
[modify] https://crrev.com/e6901925dd5b37d55accbac55564f639bf4f788a/third_party/blink/renderer/core/frame/web_view_frame_widget.cc

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

commit bb5335def24117feea48a14c5c4e2c6caf54b8c9
Author: danakj <danakj@chromium.org>
Date: Sat Oct 27 00:07:09 2018

Remove SetVisible calls when setting the root layer in WebViewImpl.

The call in SetRootGraphicsLayer() comes from this CL:
https://codereview.chromium.org/1078473002/diff/100001/Source/web/WebViewImpl.cpp#newcode4168

In that CL it mentions that visibility is not always propagated to the
WebViewImpl, but in a racey way. At that time WebViewImpl would
initialize its compositor on line 452 after SetVisibilityState on line
449.

This means at startup the compositor's visibility would not be set. It
would only be toggled if the browser send a shown IPC to the renderer,
which it appears did not always end up arriving.

Things have changed significantly since then. We now SetVisible on the
compositor in order to start its scheduler. At the time we had a
separate start signal via SetLayerTreeHostClientReady(). So now
RenderWidget would set the compositor as visible if its marked as
shown when it is created.

The call in SetRootLayer was moved in 7e410b319bf81 from
WebViewImpl::attachPaintArtifactCompositor() which included
-    // TODO(jbroman): This is cargo-culted from setRootGraphicsLayer. Is it
-    // necessary?
-    m_layerTreeView->setVisible(page()->isPageVisible());

So I would say no it is not.

R=enne@chromium.org

Change-Id: Icaea3fb4b164b9b4de348dd2e216c4a6a3344b60
Bug: 896836,  894899 
Reviewed-on: https://chromium-review.googlesource.com/c/1298341
Reviewed-by: enne <enne@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603265}
[modify] https://crrev.com/bb5335def24117feea48a14c5c4e2c6caf54b8c9/third_party/blink/renderer/core/exported/web_view_impl.cc

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

commit e9be316866cc8adf0619e15b88b4c849e8175583
Author: danakj <danakj@chromium.org>
Date: Mon Nov 05 21:32:00 2018

Reland "Don't SetVisible on swapped out RenderWidgets, and drop gpu resources."

This is a reland of 1c6f831f14152cf4ca9e23563757d61524487234

This CL made a number of flaky tests more visibly flaky. We've fixed or
disabled tests as a result of that. (See crbug.com/899073)

TBR=dcheng@chromium.org, piman@chromium.org

Original change's description:
> Don't SetVisible on swapped out RenderWidgets, and drop gpu resources.
>
> When a RenderWidget is created for a RenderViewImpl, it may be
> considered "swapped out". This means the main frame for this
> RenderView's frame tree is not local, the RenderView exists to
> hold some other local subframe, which will be composited and have
> a RenderWidget. Thus the RenderWidget attached to the RenderViewImpl
> is not actually used, there is no output from the remote main frame
> in this tree. I like to refer to these swapped out RenderWidgets as
> zombies.
>
> During navigations, a RenderViewImpl's main frame may change to or
> from being local, in which case the RenderWidget attached to it changes
> to or from being a zombie.
>
> When becoming a zombie, the WebFrameWidget attached to the
> RenderViewImpl (wrapping the WebViewImpl) is destroyed, and this
> marks the compositor as SetVisible(false) on the RenderWidget
> (via the WebViewImpl).
>
> When becoming alive again, a new WebFrameWidget is attached to the
> RenderViewImpl, and the WebFrameWidget marks the compositor as
> SetVisible(true) on the RenderWidget (via the WebViewImpl).
>
> While a zombie, the WebViewImpl is also told not to allow any
> visibility changes to be passed along to the RenderWidget. This is
> because as the local subframe becomes visible with the Page, we'd
> tell the WebView about this, to tell the Page. But since the
> WebView now has a zombie RenderWidget, it shouldn't also tell that.
>
> Note when the RenderViewImpl is created and initially swapped out
> it creates a RenderWidget but nothing tells its compositor about the
> zombie state of affairs, so it becomes visible, which makes it
> acquire a Gpu channel and start its scheduler etc. Woops.
>
> This CL rearranges things a bit.
> - A new RenderWidget does not SetVisible(true) if swapped out.
> - RenderViewImpl directly marks it SetVisible(false) when removing the
> WebFrameWidget.
> - RenderViewImpl *also* removes the LayerTreeFrameSink to drop the
> Gpu channel since we don't need to be fast at becoming visible (the
> RenderWidget is a zombie!)
> - RenderViewImpl directly marks it as SetVisible(true) when getting
> a new WebFrameWidget as the RenderWidget stops being a zombie.
> - WebViewImpl stops calling SetVisible on the RenderWidget when its
> main frame is not visible. In the future the RenderWidget should be
> a member of the main LocalFrame, and thus won't even exist when the
> main frame is not local.
>
> R=dcheng@chromium.org, piman@chromium.org
>
> Change-Id: I87a5d0dfeaaf08cb91c9348b26b4205db55b3a81
> Bug:  894899 , 419087
> Reviewed-on: https://chromium-review.googlesource.com/c/1290140
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Antoine Labour <piman@chromium.org>
> Commit-Queue: danakj <danakj@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#602389}

Bug:  894899 , 419087
Change-Id: Iaea605af085c2c866fc183bb317e98aa15cb4ab3
Reviewed-on: https://chromium-review.googlesource.com/c/1318382
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605471}
[modify] https://crrev.com/e9be316866cc8adf0619e15b88b4c849e8175583/content/renderer/gpu/layer_tree_view.cc
[modify] https://crrev.com/e9be316866cc8adf0619e15b88b4c849e8175583/content/renderer/gpu/layer_tree_view.h
[modify] https://crrev.com/e9be316866cc8adf0619e15b88b4c849e8175583/content/renderer/render_view_impl.cc
[modify] https://crrev.com/e9be316866cc8adf0619e15b88b4c849e8175583/content/renderer/render_widget.cc
[modify] https://crrev.com/e9be316866cc8adf0619e15b88b4c849e8175583/content/renderer/render_widget.h
[modify] https://crrev.com/e9be316866cc8adf0619e15b88b4c849e8175583/third_party/blink/renderer/core/exported/web_view_impl.cc
[modify] https://crrev.com/e9be316866cc8adf0619e15b88b4c849e8175583/third_party/blink/renderer/core/exported/web_view_impl.h
[modify] https://crrev.com/e9be316866cc8adf0619e15b88b4c849e8175583/third_party/blink/renderer/core/frame/web_view_frame_widget.cc

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

commit 5c5269badc764cc095a3dfa2e2735324ab50077f
Author: danakj <danakj@chromium.org>
Date: Tue Nov 06 00:39:11 2018

Stop doing WillCloseLayerTreeView() from RenderWidget::DoDeferredClose.

This old behaviour changes the shutdown order for RenderWidget/WebWidget
depending if the browser or renderer initiated the close.

In the browser case, a WidgetMsg_Close IPC arrives which posts a Close()
task. That task then does WillCloseLayerTreeView().

In the renderer case, we post a task to ask for a WidgetMsg_Close, but
in that task we also immediately WillCloseLayerTreeView(). This means
that once the WidgetMsg_Close IPC arrives and is handled, the
WebLayerTreeView has already been removed from blink, changing the
shutdown order.

It also means that in between sending a request for WidgetMsg_Close and
receiving it, other IPCs can arrive, which modify state in blink. All
these code paths can run after WillCloseLayerTreeView() and must check
if we are closing, but only for renderer-initiated close.

Instead we can be more consistent, allow those IPCs to run normally,
and never use those codepaths in blink after close. To do so we remove
WillCloseLayerTreeView() from RenderWidget::DoDeferredClose() and just
do it from RenderWidget::Close().

This also makes RenderWidget::CloseWebWidget() only called once,
instead of calling it twice when closing a child local root widget.

Last we make "are we compositing" a constant state on WebViewImpl,
and check that instead of |layer_tree_view_| to disambiguate and
clearly state that the code path is not run after closing the
connection to the compositor.

R=enne@chromium.org

Change-Id: I471717e2fe25898b37791addbad8161cabb90136
Bug: 419087,  894899 
Reviewed-on: https://chromium-review.googlesource.com/c/1292592
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605541}
[modify] https://crrev.com/5c5269badc764cc095a3dfa2e2735324ab50077f/content/renderer/render_widget.cc
[modify] https://crrev.com/5c5269badc764cc095a3dfa2e2735324ab50077f/content/renderer/render_widget.h
[modify] https://crrev.com/5c5269badc764cc095a3dfa2e2735324ab50077f/third_party/blink/renderer/core/exported/web_view_impl.cc
[modify] https://crrev.com/5c5269badc764cc095a3dfa2e2735324ab50077f/third_party/blink/renderer/core/exported/web_view_impl.h

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

commit a7425d4d913ebaec77141c72c2cf75cf8f7c95f1
Author: danakj <danakj@chromium.org>
Date: Wed Nov 07 21:35:54 2018

Remove null check in RenderViewImpl::ApplyPageVisibility.

Why would the browser be changing the page visibility after it has
detached the main frame, closing the RenderWidget and destroying the
WebView? It wouldn't.

R=dcheng@chromium.org

Change-Id: Ibc49c8b9ffbcf174819d88423125ca2e47c775d8
Bug:  894899 
Reviewed-on: https://chromium-review.googlesource.com/c/1323698
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606170}
[modify] https://crrev.com/a7425d4d913ebaec77141c72c2cf75cf8f7c95f1/content/renderer/render_view_impl.cc

https://chromium-review.googlesource.com/c/1292714 completes this, forgot to link it to this.

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

commit 678f025f7cde75d3c4c9dddbaefde07aec197faa
Author: danakj <danakj@chromium.org>
Date: Fri Nov 09 21:46:34 2018

Reland "Don't make a LayerTreeFrameSink for a non-visible RenderWidget."

This is a reland of 68d8dbc019fd37659252e273ade868aac7a9d8ac

The flaky test this caused to fail is flaky before this CL. Investigation
in https://bugs.chromium.org/p/chromium/issues/detail?id=903695.

I will disable it if I can't resolve it.

TBR=

Original change's description:
> Don't make a LayerTreeFrameSink for a non-visible RenderWidget.
>
> Importantly, non-visible RenderWidgets include swapped out RenderWidgets
> which are zombies, without a frame, and which should not be used.
>
> This can happen if the RenderWidget swap out races with the posted task
> from the compositor to make a LayerTreeFrameSink. When swapping out, the
> compositor would be marked as not-visible, which would stop it from
> making such requests, but one could already be in flight.
>
> In the other case, honoring the request for a non-visible compositor is
> more benign, but we can delay it until the compositor is actually
> visible again. This means if a context is lost, backgrounded tabs would
> not all attempt to reconnect to the Gpu process at once.
>
> This is a better followup for the hacky
> https://chromium-review.googlesource.com/c/chromium/src/+/1292711 which
> was meant only for merge to a release branch. It reverts that change as
> part of this one.
>
> R=piman@chromium.org
>
> Change-Id: I058bdc37482d04bb86d65a7377b7520dad8573e7
> Bug: 896836, 419087
> Reviewed-on: https://chromium-review.googlesource.com/c/1292714
> Commit-Queue: danakj <danakj@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Antoine Labour <piman@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#606655}

Bug: 896836, 419087,  894899 
Change-Id: Ic82c9c61d0e3154e20352470636e09b13248d775
Reviewed-on: https://chromium-review.googlesource.com/c/1329546
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606981}
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/renderer/gpu/layer_tree_view.cc
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/renderer/gpu/layer_tree_view_delegate.h
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/renderer/input/widget_input_handler_impl.cc
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/renderer/input/widget_input_handler_manager.cc
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/renderer/render_view_impl.cc
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/renderer/render_widget.cc
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/renderer/render_widget.h
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/test/stub_layer_tree_view_delegate.cc
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/content/test/stub_layer_tree_view_delegate.h
[modify] https://crrev.com/678f025f7cde75d3c4c9dddbaefde07aec197faa/third_party/blink/renderer/core/exported/web_view_impl.cc

May still be happening, investigating if it's this or another reason in 896836

opening cuz blockers

This is actually fixed, but sometimes a main RenderWidget without a frame does end up making a frame sink, but it's not swapped out. It's a case where the frame was detached directly. This is covered by the blocking bug 906340. I'll leave this blocking on that but close this one as we're done for SwappedOut.