Simplify and solidify FrameView dirty layout check

Simplify and solidify FrameView dirty layout check

Issues to debug:
- dirty layout immediately after layout() in
  FrameView::updateStyleAndLayoutIfNeededRecursiveInternal();
- dirty frame layout during painting, though with existing layout
  invalidation checks.

Remove m_inPluginUpdate and m_inForcedLayoutByChildEmbeddedReplacedContent
which were for special casing layout invalidation during layout. Now just
assumes layout invalidation is allowed during layout.

And solidify dirty layout check:
- check all early return conditions of layout() in
  updateStyleAndLayoutIfNeededRecursiveInternal();
- check all frames in updateDocumentLifecyclePhasesInternal() after layout
  stage.

BUG=590856
Committed: https://crrev.com/d6fcf50124b2bb0cf0f9c238ea1c792d63fa3d8c
Cr-Commit-Position: refs/heads/master@{#404256}

[Xianzhu, 2016-07-07 02:09:54]

Description was changed from

==========
FrameView dirty layout check

BUG=590856
==========

to

==========
Simplify and solidify FrameView dirty layout check

Remove m_inPluginUpdate and m_inForcedLayoutByChildEmbeddedReplacedContent
which were for special casing layout invalidation during layout. Now just
assumes layout invalidation is allowed during layout.

And solidify dirty layout check by checking all frames in
updateDocumentLifecyclePhasesInternal() after layout stage.

BUG=590856
==========

[Xianzhu, 2016-07-07 02:11:21]

Description was changed from

==========
Simplify and solidify FrameView dirty layout check

Remove m_inPluginUpdate and m_inForcedLayoutByChildEmbeddedReplacedContent
which were for special casing layout invalidation during layout. Now just
assumes layout invalidation is allowed during layout.

And solidify dirty layout check by checking all frames in
updateDocumentLifecyclePhasesInternal() after layout stage.

BUG=590856
==========

to

==========
Simplify and solidify FrameView dirty layout check

Issues to debug:
- dirty layout immediately after FrameView::layout();
- dirty frame layout during painting, though with existing layout
  invalidation checks.

Remove m_inPluginUpdate and m_inForcedLayoutByChildEmbeddedReplacedContent
which were for special casing layout invalidation during layout. Now just
assumes layout invalidation is allowed during layout.

And solidify dirty layout check by checking all frames in
updateDocumentLifecyclePhasesInternal() after layout stage.

BUG=590856
==========

[Xianzhu, 2016-07-07 02:38:09]

Description was changed from

==========
Simplify and solidify FrameView dirty layout check

Issues to debug:
- dirty layout immediately after FrameView::layout();
- dirty frame layout during painting, though with existing layout
  invalidation checks.

Remove m_inPluginUpdate and m_inForcedLayoutByChildEmbeddedReplacedContent
which were for special casing layout invalidation during layout. Now just
assumes layout invalidation is allowed during layout.

And solidify dirty layout check by checking all frames in
updateDocumentLifecyclePhasesInternal() after layout stage.

BUG=590856
==========

to

==========
Simplify and solidify FrameView dirty layout check

Issues to debug:
- dirty layout immediately after layout() in
  FrameView::updateStyleAndLayoutIfNeededRecursiveInternal();
- dirty frame layout during painting, though with existing layout
  invalidation checks.

Remove m_inPluginUpdate and m_inForcedLayoutByChildEmbeddedReplacedContent
which were for special casing layout invalidation during layout. Now just
assumes layout invalidation is allowed during layout.

And solidify dirty layout check:
- check all early return conditions of layout() in
  updateStyleAndLayoutIfNeededRecursiveInternal();
- check all frames in updateDocumentLifecyclePhasesInternal() after layout
  stage.

BUG=590856
==========

[Xianzhu, 2016-07-07 02:38:43]

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

[szager1, 2016-07-07 18:55:30]

lgtm w/nit

https://codereview.chromium.org/2120773002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/2120773002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/FrameView.cpp:2504:
forAllNonThrottledFrameViews([](FrameView& frameView) {
It's probably a minor point, but this becomes O(N^2), because
forAllNonThrottledFrameViews recurses all the way down the frame tree, and
updateStyleAndLayoutIfNeededRecursive will recurse back into this method.

Probably not a big deal in practice, but maybe worth a comment.

https://codereview.chromium.org/2120773002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/FrameView.cpp:2676:
CHECK(!m_nestedLayoutCount);
Nice!

[Xianzhu, 2016-07-07 19:06:06]

https://codereview.chromium.org/2120773002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/2120773002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/FrameView.cpp:2504:
forAllNonThrottledFrameViews([](FrameView& frameView) {
On 2016/07/07 18:55:29, szager1 wrote:
> It's probably a minor point, but this becomes O(N^2), because
> forAllNonThrottledFrameViews recurses all the way down the frame tree, and
> updateStyleAndLayoutIfNeededRecursive will recurse back into this method.
> 
> Probably not a big deal in practice, but maybe worth a comment.

It seems wrong that this function is recursed. Trying by adding
CHECK(frameView.m_allowsLayoutInvalidationAfterLayoutClean) to see if there is
recursion.

[szager1, 2016-07-07 19:12:42]

lgtm

https://codereview.chromium.org/2120773002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/2120773002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/FrameView.cpp:2504:
forAllNonThrottledFrameViews([](FrameView& frameView) {
On 2016/07/07 19:06:06, Xianzhu wrote:
> On 2016/07/07 18:55:29, szager1 wrote:
> > It's probably a minor point, but this becomes O(N^2), because
> > forAllNonThrottledFrameViews recurses all the way down the frame tree, and
> > updateStyleAndLayoutIfNeededRecursive will recurse back into this method.
> > 
> > Probably not a big deal in practice, but maybe worth a comment.
> 
> It seems wrong that this function is recursed. Trying by adding
> CHECK(frameView.m_allowsLayoutInvalidationAfterLayoutClean) to see if there is
> recursion.

Oh yes, you are right; never mind my comment.

[Xianzhu, 2016-07-07 19:38:00]

The CQ bit was checked by wangxianzhu@chromium.org

[commit-bot: I haz the power, 2016-07-07 19:38:54]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-07 22:20:30]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-07-07 22:20:57]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-07 22:23:34]

Description was changed from

==========
Simplify and solidify FrameView dirty layout check

Issues to debug:
- dirty layout immediately after layout() in
  FrameView::updateStyleAndLayoutIfNeededRecursiveInternal();
- dirty frame layout during painting, though with existing layout
  invalidation checks.

Remove m_inPluginUpdate and m_inForcedLayoutByChildEmbeddedReplacedContent
which were for special casing layout invalidation during layout. Now just
assumes layout invalidation is allowed during layout.

And solidify dirty layout check:
- check all early return conditions of layout() in
  updateStyleAndLayoutIfNeededRecursiveInternal();
- check all frames in updateDocumentLifecyclePhasesInternal() after layout
  stage.

BUG=590856
==========

to

==========
Simplify and solidify FrameView dirty layout check

Issues to debug:
- dirty layout immediately after layout() in
  FrameView::updateStyleAndLayoutIfNeededRecursiveInternal();
- dirty frame layout during painting, though with existing layout
  invalidation checks.

Remove m_inPluginUpdate and m_inForcedLayoutByChildEmbeddedReplacedContent
which were for special casing layout invalidation during layout. Now just
assumes layout invalidation is allowed during layout.

And solidify dirty layout check:
- check all early return conditions of layout() in
  updateStyleAndLayoutIfNeededRecursiveInternal();
- check all frames in updateDocumentLifecyclePhasesInternal() after layout
  stage.

BUG=590856

Committed: https://crrev.com/d6fcf50124b2bb0cf0f9c238ea1c792d63fa3d8c
Cr-Commit-Position: refs/heads/master@{#404256}
==========

[commit-bot: I haz the power, 2016-07-07 22:23:35]

Patchset 4 (id:??) landed as
https://crrev.com/d6fcf50124b2bb0cf0f9c238ea1c792d63fa3d8c
Cr-Commit-Position: refs/heads/master@{#404256}