Allow local root FrameView to be throttled

third_party/WebKit/Source/core/frame/FrameView.cpp

Index: third_party/WebKit/Source/core/frame/FrameView.cpp
diff --git a/third_party/WebKit/Source/core/frame/FrameView.cpp b/third_party/WebKit/Source/core/frame/FrameView.cpp
index dd65fe3998e1f0588f41f1628eec4cdcbbd8e2e7..c3d97899d89a7ce8cefc62d3b98f38d5eeccdc7a 100644
--- a/third_party/WebKit/Source/core/frame/FrameView.cpp
+++ b/third_party/WebKit/Source/core/frame/FrameView.cpp
@@ -2368,6 +2368,11 @@ void FrameView::updateLifecyclePhasesInternal(LifeCycleUpdateOption phases)
     // Updating layout can run script, which can tear down the FrameView.
     RefPtrWillBeRawPtr<FrameView> protector(this);
 
+    if (shouldThrottleRendering()) {
+        updateViewportIntersectionsForSubtree();

[ojan, 2015/12/01 01:11:05]

Do we need to update the intersections for the subtree if we're throttled?

As I look more closely, do we need to update the intersections in the
OnlyUpToLayoutClean early return either?

It seems to me that in both cases we only need to do this if we're running the
whole pipeline unthrottled (for this subtree). I'm probably missing some
complication though.

The early return here makes sense to me though.

[Sami, 2015/12/04 18:39:53]

We need to update the subtree in both cases because otherwise we could end up in
a situation where the root becomes throttled but the whole subtree isn't also
marked throttled. This leads to failing lifecycle asserts because the subtree's
lifecycle is in some random state (because the root was throttled) but the
throttled flag isn't set.

N.B. updateViewportIntersectionsForSubtree() has early-outs so in the common
case it won't do much work.

+        return;
+    }
+
     updateStyleAndLayoutIfNeededRecursive();
     ASSERT(lifecycle().state() >= DocumentLifecycle::LayoutClean);