Make sure newly created frames become throttled

Make sure newly created frames become throttled

If an iframe is created inside a throttled frame, there is a window in
time before it realizes it should also become throttled. If the
following sequence of events happens in this window, FramePainter fails
with a release assert due to stale layout information:

1. The newly created frame requires GraphicsLayers (i.e., it has a CSS
   3D transform).

2. Something causes a full lifecycle update (including painting) without
   allowing throttling. As a side effect GraphicsLayers are created for
   the frame.

3. The contents of the frame are invalidated, marking it as needing
   layout.

4. One or more GraphicsLayers for the frame are also marked as needing
   repaint.

5. We do a BeginMainFrame. This allows throttling, so we do not update
   the lifecycle for the newly created frame. However in the
   synchronized painting stage we descend through the full GraphicsLayer
   tree. When we reaches a GraphicsLayer the newly created frame, a
   release assert fails because the respective FrameView needs layout.

This patch fixes the bug by updating the throttling status of a frame as
soon as it is assigned a parent.

BUG=609758

[Sami, 2016-05-12 10:32:21]

Description was changed from

==========
Make sure newly created frames become throttled

If an iframe is created inside a throttled frame, there is a window in
time before it realizes it should also become throttled. If the
following sequence of events happens in this window, FramePainter fails
with a release assert due to stale layout information:

1. The newly created frame requires GraphicsLayers (i.e., it has a CSS
   3D transform).

2. Something causes a full lifecycle update (including painting) without
   allowing throttling. As a side effect GraphicsLayers are created for
   the frame.

3. The contents of the frame are invalidated, marking it as needing
   layout.

4. One or more GraphicsLayers for the frame are also marked as needing
   repaint.

5. We do a BeginMainFrame. This allows throttling, so we do not update
   the lifecycle for the newly created frame. However in the
   synchronized painting stage we descend through the full GraphicsLayer
   tree. When we reaches a GraphicsLayer the newly created frame, a
   release assert fails because the respective FrameView needs layout.

This patch fixes the bug by updating the throttling status of a frame as
soon as it is assigned a parent.

BUG=609758
==========

to

==========
Make sure newly created frames become throttled

If an iframe is created inside a throttled frame, there is a window in
time before it realizes it should also become throttled. If the
following sequence of events happens in this window, FramePainter fails
with a release assert due to stale layout information:

1. The newly created frame requires GraphicsLayers (i.e., it has a CSS
   3D transform).

2. Something causes a full lifecycle update (including painting) without
   allowing throttling. As a side effect GraphicsLayers are created for
   the frame.

3. The contents of the frame are invalidated, marking it as needing
   layout.

4. One or more GraphicsLayers for the frame are also marked as needing
   repaint.

5. We do a BeginMainFrame. This allows throttling, so we do not update
   the lifecycle for the newly created frame. However in the
   synchronized painting stage we descend through the full GraphicsLayer
   tree. When we reaches a GraphicsLayer the newly created frame, a
   release assert fails because the respective FrameView needs layout.

This patch fixes the bug by updating the throttling status of a frame as
soon as it is assigned a parent.

BUG=609758
==========

[Sami, 2016-05-12 10:32:21]

skyostil@chromium.org changed reviewers:
+ wangxianzhu@chromium.org

[Sami, 2016-05-12 10:33:43]

I was finally able to reproduce the FrameView release assertion failure. It
required a pretty elaborate setup, but I think this could still plausibly be
happening on real pages.

Interestingly this doesn't hit the assert anymore after
https://codereview.chromium.org/1954093003 but I think it's still worth fixing.
PTAL.

[Sami, 2016-05-12 15:12:02]

Looks like this is causing some general unhappiness in the layout tests. I'll
investigate and report back.