summaryrefslogtreecommitdiffstats
path: root/base
diff options
context:
space:
mode:
authorbokan <bokan@chromium.org>2016-03-09 06:32:58 -0800
committerCommit bot <commit-bot@chromium.org>2016-03-09 14:34:14 +0000
commit5fe2fbbfe5061a6bb512d3866470d2bbf2c6c6d8 (patch)
tree483298411a842db682f16dfbbaba92c79f4f880e /base
parent17f1c1ded552cbcd11cac1b7985593ea2c847808 (diff)
downloadchromium_src-5fe2fbbfe5061a6bb512d3866470d2bbf2c6c6d8.zip
chromium_src-5fe2fbbfe5061a6bb512d3866470d2bbf2c6c6d8.tar.gz
chromium_src-5fe2fbbfe5061a6bb512d3866470d2bbf2c6c6d8.tar.bz2
Dispose of RootFrameViewport's ScrollAnimator during FrameView::dispose
ScrollAnimators are held from objects which are not garbage collected. When FrameView is disposed, it clears its ScrollAnimators so we don't make calls into the disposed FrameView via these non-GC'd objects. However, we weren't clearing the RootFrameViewport's ScrollAnimators. This meant that the FrameView gets disposed but the OS in Mac will make a call to ScrollAnimatorMac which in turn makes a call into its RootFrameViewport which calls into the disposed FrameView causing a use-after-free when the FrameView touches a deleted PaintLayer. Since the root FrameView owns the RootFrameViewport, it makes sense to clear its animators at the same time. BUG=582755 Review URL: https://codereview.chromium.org/1756273003 Cr-Commit-Position: refs/heads/master@{#380135}
Diffstat (limited to 'base')
0 files changed, 0 insertions, 0 deletions