[Webkit-unassigned] [Bug 70395] REGRESSION: rtl horizontal scrollbar / resize bug - Body shifts on resize when scrolled all the way to the left

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 19 16:17:13 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=70395


Xiaomei Ji <xji at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|rtl horizontal scrollbar /  |REGRESSION: rtl horizontal
                   |resize bug - Body shifts on |scrollbar / resize bug -
                   |resize when scrolled all    |Body shifts on resize when
                   |the way to the left         |scrolled all the way to the
                   |                            |left
             Status|UNCONFIRMED                 |NEW
                 CC|                            |xji at chromium.org
     Ever Confirmed|0                           |1




--- Comment #2 from Xiaomei Ji <xji at chromium.org>  2011-10-19 16:17:13 PST ---
It appears regressed in http://trac.webkit.org/changeset/76395/trunk.

If I remove the condition checking in ScrollAnimator::scrollToOffsetWithoutAnimation(), the test case works ok (tested in chromium, Safari in Mac works fine since it has its own ScrollAnimatorMac.mm, in which, ScollTo() is always called without condition).

But I am not sure removing the condition checking is the right fix.
Would appreciate comments from mitz (who added ScrollView.cpp#L586) and/or weinig (who is more familiar with ScrollAnimation).

The reason of the failure is that:
when horizontal scrollbar is at leftmost, ScrollAnimator::m_currentPosX/Y == 0.

when enlarge browser size, following is part of the call stack:
        ......
     ScrollView::updateScrollbars(...)
     ScrollView::setScrollOrigin(...)
     FrameView::adjustViewSize(...)
        .....

Assume m_scrollOrigin.x was 200 previously, and is 150 now, at inline http://trac.webkit.org/browser/trunk/Source/WebCore/platform/ScrollView.cpp#L586
desiredOffset is the old scroll offset, which is -200, and adjustScrollPositionWithinRange() will adjust it within the range of (-150, 0) using current m_scrollOrigin, and scrollPoint is always >= 0.

After the above line, the scrollPoint passed to ScrollAnimator::scrollToOffsetWithoutAnimation() is (0, 0), since it is the same as m_currentPosX/Y, notifyPositionChanged() will *not* be called, so FrameView::scrollTo() using current m_scrollOrigin etc. are not called, caused wrong/mis-match of scroll position with document body.

It looks to me that ScrollAnimator::m_currentPosX and the parameter passing to ScrollAnimator::scrollToOffsetWithoutAnimation() are positive values even the scroll positions are negative values for RTL pages. I do not know the reason, but if that is the case, ScrollView.cpp#L58 seems doing the right thing, and we probably have to always scroll without condition checking.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list