[webkit-reviews] review denied: [Bug 95322] [chromium] Fix double call to scrollBegin() when handling scroll gesture : [Attachment 162253] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Sep 5 10:49:27 PDT 2012
James Robinson <jamesr at chromium.org> has denied Iain Merrick
<husky at chromium.org>'s request for review:
Bug 95322: [chromium] Fix double call to scrollBegin() when handling scroll
gesture
https://bugs.webkit.org/show_bug.cgi?id=95322
Attachment 162253: Patch
https://bugs.webkit.org/attachment.cgi?id=162253&action=review
------- Additional Comments from James Robinson <jamesr at chromium.org>
View in context: https://bugs.webkit.org/attachment.cgi?id=162253&action=review
> Source/WebKit/chromium/ChangeLog:23
> + doesn't seem to represent normal usage -- composited flings don't
turn into
> + main thread flings halfway through.
Sorry, yes they do for wheel flings. This test and the behavior it tests are
important.
> Source/WebKit/chromium/src/WebCompositorInputHandlerImpl.cpp:333
> + m_inputHandlerClient->scrollBy(IntPoint(m_wheelFlingParameters.point.x,
m_wheelFlingParameters.point.y),
This doesn't look right. Keep in mind we have 2 kinds of flings - "gesture"
flings and "wheel pad" flings. The former is what Chrome on android has. The
latter - which is what this code implements - works like OS X fling by
generating a sequence of synthetic wheel events.
It looks like you've just deleted the code for the second kind of fling
completely. That's definitely not the right fix!
I think what you really want to do is for wheel fling type scrolls send a
matching scrollEnd() to the scrollBegin() when the fling starts.
More information about the webkit-reviews
mailing list