https://bugs.webkit.org/show_bug.cgi?id=89114
authorbdakin@apple.com <bdakin@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 25 Jul 2012 18:15:17 +0000 (18:15 +0000)
committerbdakin@apple.com <bdakin@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 25 Jul 2012 18:15:17 +0000 (18:15 +0000)
commit9efd1a23e87aef28d89c176091de116943ff03a6
tree34d024e59302985d3d65bcbaf2ea4b3ee164fe26
parentbb835db4d6d61622829eb8eff99f40eb629a6472
https://bugs.webkit.org/show_bug.cgi?id=89114
REGRESSION (r112919): Setting scrollTop after setting display from none to block
fails
-and corresponding-
<rdar://problem/11656050>

Reviewed by Simon Fraser.

Source/WebCore:

ScrollAnimatorMac::immediateScrollTo() and ScrollAnimatorMac::immediateScrollBy()
both have an optimization in place so that they do not call
notifyPositionChanged() if the new scroll offset matches the ScrollAnimator's
cached m_currentPosX and m_currentPosY. So revision 112919 caused troubled with
this optimization because it allowed RenderLayers to restore a scrollOffset from
the Element if there is one cached there. This caused the RenderLayer to have a
scrollOffset that is improperly out-of-synch with the ScrollAnimator's
currentPosition (which will just be 0,0 since it is being re-created like the
RenderLayer). This fix makes sure they are in synch by calling
setCurrentPosition() on the ScrollAnimator when the cached position is non-zero.
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::RenderLayer):

LayoutTests:

* fast/overflow/setting-scrollTop-after-hide-show-expected.txt: Added.
* fast/overflow/setting-scrollTop-after-hide-show.html: Added.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@123637 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/fast/overflow/setting-scrollTop-after-hide-show-expected.txt [new file with mode: 0644]
LayoutTests/fast/overflow/setting-scrollTop-after-hide-show.html [new file with mode: 0644]
Source/WebCore/ChangeLog
Source/WebCore/rendering/RenderLayer.cpp