[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