commit 04d55bb599cf00bc0e7493795add44fefff33721
author danakj <danakj@chromium.org> Wed Feb 13 20:28:10 2019
committer Commit Bot <commit-bot@chromium.org> Wed Feb 13 20:28:10 2019
tree 1e6841570a78fd95358c4a60ad9855b322b058ca
parent 13bad8e092f2916533b3adb74d2136474aa5c070

Remove AttachCompositorAnimationTimeline from WebFrameWidget creation.

This branch in WebLocalFrameImpl::SetFrameWidget() to attach the
compositor timeline was added in f5af1abbbe19b919a claiming that
Document::Initialize() may be called for a LocalFrame that has not
attached a WebFrameWidget yet.

I claim that this does occur but only in cases where the LocalFrame
will /never/ have a WebFrameWidget so doing this later in that case
is pointless. And this ends up attempting to attach a compositor
timeline in the middle of creating WebFrameWidgetImpl - when it does
not have an initialized WebWidgetClient (aka RenderWidget) and thus
has no LayerTreeView or AnimationHost setup for it yet. Thus the code
path goes to ChromeClientImpl and simply returns due to null pointer.

So in both cases this is not needed. Further points below.

In the first case, we do see Document::Initialize() called for
LocalFrame before it is attached to a local root when
LocalFrame::ForceSynchronousDocumentInstall() is called. This is done
in cases where the LocalFrame hosts an orphan Page object, and is used
for painting into the "real" Document/Page, such as for SVG, inspector
overlays, validation overlays. Since these are orphan Pages, the frame
is never attached and WebLocalFrameImpl::SetFrameWidget() would not
occur.

ForceSynchronousDocumentInstall() is also used for WebPagePopupImpl
which is not a frame, so does not ever have a WebFrameWidget.

In the second case, Document::Initialize() is called from:
- CommitNavigation: This is after the local root frame has a
WebFrameWidget attached to it. The WebFrameWidget is attached inside
RenderFrameImpl::CreateFrame(), whereas CommitNavigation happens in
another call stack.
- ReplaceDocumentWhileExecutingJavaScriptURL: this is also done from
another stack, not from inside RenderFrameImpl::CreateFrame() between
the WebFrame being created and the WebFrameWidget.
- XSLTProcessor::CreateDocumentFromSource: this is called only if the
frame already exists and has a document - which was already
initialized. So we know it already satisfies having a WebFrameWidget
by induction.

R=pdr@chromium.org, wangxianzhu@chromium.org

Bug: 912193
Change-Id: I6c8e71c2710110f51a686f63cc6fe49b8adcadfb
Reviewed-on: https://chromium-review.googlesource.com/c/1468596
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#631875}