Occasional crash under AsyncScrollingCoordinator::frameViewRootLayerDidChange() on...
authorsimon.fraser@apple.com <simon.fraser@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 9 May 2014 02:26:22 +0000 (02:26 +0000)
committersimon.fraser@apple.com <simon.fraser@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 9 May 2014 02:26:22 +0000 (02:26 +0000)
commitabb6d8e3d8e79df6e3a7bbfd25b6968fc4a2a60c
treea82c59cde5dc75ce10f9940c9878722f7d0cf83e
parent659e8c64f0d4bd50786f68e01cc77df3dd0095bf
Occasional crash under AsyncScrollingCoordinator::frameViewRootLayerDidChange() on history navigation
https://bugs.webkit.org/show_bug.cgi?id=132723

Reviewed by Sam Weinig.

Crash reports suggest that when we call AsyncScrollingCoordinator::frameViewRootLayerDidChange()
from HistoryController::restoreScrollPositionAndViewState(), the FrameView may not have a
scrolling node ID, which suggests that either the FrameView doesn't have a RenderView,
or compositing hasn't happened yet.

So if we enter AsyncScrollingCoordinator::frameViewRootLayerDidChange()
and the FrameView has no scrollLayerID, just return. We'll fix things up
when compositing kicks in later.

* page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::frameViewRootLayerDidChange):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@168514 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore/ChangeLog
Source/WebCore/page/scrolling/AsyncScrollingCoordinator.cpp