Bug 89371 – [BlackBerry] Overscroll can get reset while interacting with a page, due to style recalculations and scroll position clamping

• Component: WebKit BlackBerry
• Status: RESOLVED FIXED

[Antonio Gomes]

From PRZilla:

(Issue found while investigating PR #152333).

while user is scrolling, an webpage can have style recalculations or relayout triggered that at some point can clamp the scroll position to 0,0. See the stack trace below:

(gdb) bt
#0  ScrollHandlerUserInterfaceThread::updateScrollPosition (this=0x18e230, pos=...) at
#1  0x782b4a3e in WebPageClientImpl::scrollChanged (this=0x1923b8, scrollPoint=...) at
#2  0x78147484 in BlackBerry::WebKit::WebPagePrivate::notifyTransformedScrollChanged
#3  0x78171f68 in BlackBerry::WebKit::BackingStoreClient::checkOriginOfCurrentScrollOperation
#4  0x7816480a in WebCore::ChromeClientBlackBerry::scroll (this=0x13fd10, delta=..., scrollViewRect=..., clipRect=...)
#5  0x7a78b290 in WebCore::Chrome::scroll (this=<optimized out>, scrollDelta=..., rectToScroll=..., clipRect=...)
#6  0x7a7ac8d0 in WebCore::FrameView::scrollContentsFastPath (this=0x323c90, scrollDelta=..., rectToScroll=..., clipRect=...)
#7  0x7a7eba72 in WebCore::ScrollView::scrollContents (this=0x323c90, scrollDelta=...) at
#8  0x7a7ebb34 in WebCore::ScrollView::scrollTo (this=0x323c90, newOffset=...)at
#9  0x7a7a8dae in WebCore::FrameView::scrollTo (this=<optimized out>, newOffset=...) at
#10 0x7a7e966e in WebCore::ScrollView::setScrollOffset (this=0x323c90, offset=...) at
#11 0x7a7e77cc in WebCore::ScrollableArea::scrollPositionChanged(this=0x323cb4, position=...) at
#12 0x7a7e7048 in WebCore::ScrollAnimator::notifyPositionChanged
#13 0x7a7e700c in WebCore::ScrollAnimator::scrollToOffsetWithoutAnimation(this=<optimized out>, offset=...)
#14 0x7a7e7588 in WebCore::ScrollableArea::scrollToOffsetWithoutAnimation(this=<optimized out>, offset=...)
#15 0x7a7eaa20 in updateScrollbars (desiredOffset=..., this=0x323c90) at
#16 WebCore::ScrollView::updateScrollbars (this=0x323c90, desiredOffset=...) at
#17 0x7a7ebc8a in setContentsSize (newSize=..., this=0x323c90) at
#18 WebCore::ScrollView::setContentsSize (this=0x323c90, newSize=...) at
#19 0x7a7accd8 in WebCore::FrameView::setContentsSize (this=0x323c90, size=...) at
#20 0x7a7a85f4 in WebCore::FrameView::adjustViewSize (this=0x323c90) at
#21 0x7a7abd48 in layout (allowSubtree=<optimized out>, this=0x323c90) at
#22 WebCore::FrameView::layout (this=0x323c90, allowSubtree=<optimized out>) at
#23 0x7a59d66e in WebCore::Document::updateLayoutIgnorePendingStylesheets
#24 0x7a5ada92 in WebCore::Element::offsetHeight (this=<optimized out>) at
#25 0x7ab226b6 in WebCore::jsElementOffsetHeight (exec=<optimized out>, slotBase=...)
#26 0x796dca76 in getValue (propertyName=..., exec=0x700520, this=0x2ea570) at
#27 JSC::JSValue::get (this=<optimized out>, exec=0x700520, propertyName=..., slot=...) at
#28 0x796dd662 in JSC::JITStubThunked_op_get_by_id_generic (args=<optimized out>) at

In frame #15, we can in some cases clamp the scroll position to the mainframe
contents boundary, removing suddenly the overscroll.

This happens because our scroll operation looks like this:

void WebPage::setScrollPosition(const Platform::IntPoint& point)
{
     ...
     d->m_backingStoreClient->setIsClientGeneratedScroll(true);
     d->m_mainFrame->view()->setConstrainsScrollingToContentEdge(false);
     d->setScrollPosition(d->mapFromTransformed(point));
     d->m_mainFrame->view()->setConstrainsScrollingToContentEdge(true);
     d->m_backingStoreClient->setIsClientGeneratedScroll(false);
}

We wrap ::setScrollPosition calls with ::setConstrainsScrollingToContentEdge(false|true) calls. If webcore relayouts while setConstrainsScrollingToContentEdge is true, the scroll position will get clamped.

[Antonio Gomes]

Created attachment 148158 [details]
(committed r120622, r=atreat) patch