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.
Created attachment 148158 [details] (committed r120622, r=atreat) patch