Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
#nested is removed, ScrollAnchor::clear will first be called on #div's PLSA.
This will do nothing for #div (since it doesn't have an anchor), but will clear
the scroll anchor for #main (and not #nested because layoutObject->parent() is null
since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will be
called on #nested's PLSA and we will be working with a stale anchor.

BUG=656314
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Committed: https://crrev.com/889397888480b49f01ed18a04ce9eb05f30ca2b5
Cr-Commit-Position: refs/heads/master@{#426314}

[ymalik, 2016-10-19 15:30:00]

Description was changed from

==========
Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
and this will subsequently clear the scroll anchor for #main (and not #nested
because anchor->parent() is null since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the
IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will
be
called on #nested's PLSA and we will be working with a stale anchor.

BUG=656314
==========

to

==========
Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
and this will subsequently clear the scroll anchor for #main (and not #nested
because anchor->parent() is null since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the
IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will
be
called on #nested's PLSA and we will be working with a stale anchor.

BUG=656314
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[ymalik, 2016-10-19 15:31:15]

ymalik@chromium.org changed reviewers:
+ skobes@chromium.org

[ymalik, 2016-10-19 15:43:57]

Description was changed from

==========
Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
and this will subsequently clear the scroll anchor for #main (and not #nested
because anchor->parent() is null since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the
IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will
be
called on #nested's PLSA and we will be working with a stale anchor.

BUG=656314
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
#nested is removed, ScrollAnchor::clear will first be called on #div's PLSA.
This will do nothing for #div (since it doesn't have an anchor), but will clear 
the scroll anchor for #main (and not #nested because layoutObject->parent() is
null 
since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the
IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will
be
called on #nested's PLSA and we will be working with a stale anchor.

BUG=656314
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[skobes, 2016-10-19 15:46:29]

lgtm

Great analysis :)

[ymalik, 2016-10-19 17:10:08]

The CQ bit was checked by ymalik@chromium.org

[commit-bot: I haz the power, 2016-10-19 17:10:35]

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-10-19 19:50:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-19 19:50:06]

Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[ymalik, 2016-10-19 21:46:08]

The CQ bit was checked by ymalik@chromium.org

[commit-bot: I haz the power, 2016-10-19 21:46:45]

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-10-19 22:45:42]

Description was changed from

==========
Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
#nested is removed, ScrollAnchor::clear will first be called on #div's PLSA.
This will do nothing for #div (since it doesn't have an anchor), but will clear 
the scroll anchor for #main (and not #nested because layoutObject->parent() is
null 
since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the
IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will
be
called on #nested's PLSA and we will be working with a stale anchor.

BUG=656314
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
#nested is removed, ScrollAnchor::clear will first be called on #div's PLSA.
This will do nothing for #div (since it doesn't have an anchor), but will clear 
the scroll anchor for #main (and not #nested because layoutObject->parent() is
null 
since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the
IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will
be
called on #nested's PLSA and we will be working with a stale anchor.

BUG=656314
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

[commit-bot: I haz the power, 2016-10-19 22:45:43]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-10-21 13:12:33]

Description was changed from

==========
Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
#nested is removed, ScrollAnchor::clear will first be called on #div's PLSA.
This will do nothing for #div (since it doesn't have an anchor), but will clear 
the scroll anchor for #main (and not #nested because layoutObject->parent() is
null 
since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the
IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will
be
called on #nested's PLSA and we will be working with a stale anchor.

BUG=656314
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Fix crash when calling ScrollAnchor::clear from PaintLayer's destructor

ScrollAnchor::clear walks up the PaintLayer chain from the anchor (or its
scroller's LayoutBox if anchor is null). It unconditionally clears the
isScrollAnchorObject bit because the assumption is that if any ancestor
scroller had this LayoutObject as its anchor, it will be cleared anyway. This
only applies to clears caused by scrolling.

For example, say that you have a nested scroller (#nested) and a main frame
scroller (#main). Say that the nested scroller has a div (#div) that has its own
PaintLayer (see the test added in this CL).

Say that both #main and #nested are anchored to #something inside #nested. If
#nested is removed, ScrollAnchor::clear will first be called on #div's PLSA.
This will do nothing for #div (since it doesn't have an anchor), but will clear
the scroll anchor for #main (and not #nested because layoutObject->parent() is
null
since #div is detached from the tree).

After a call to ScrollAnchor::clear on the #div's PLSA, the IsScrollAnchorObject
bit on #something is cleared. But, #nested still holds a reference to #something
because LayoutObject::willBeRemovedFromTree check whether the
IsScrollAnchorObject
bit is set before clearing referencing scrollers. Then ScrollAnchor::clear will
be
called on #nested's PLSA and we will be working with a stale anchor.

BUG=656314
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Committed: https://crrev.com/889397888480b49f01ed18a04ce9eb05f30ca2b5
Cr-Commit-Position: refs/heads/master@{#426314}
==========

[commit-bot: I haz the power, 2016-10-21 13:12:33]

Patchset 1 (id:??) landed as
https://crrev.com/889397888480b49f01ed18a04ce9eb05f30ca2b5
Cr-Commit-Position: refs/heads/master@{#426314}