Bug 45560 – Expose an entry point to Chrome for scrolling portions of the page

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit API

[Robert Kroeger]

It is desirable under certain circumstances (inertial scroll for example) for the Chromium RenderWidget to be able to request portions of the contained WebWidget to scroll as if it were the target of mouse wheel events. I propose adding a method gestureScroll to the WebWidget in chromium/public/WebWidget to provide this functionality: calling gestureScroll results in the same behaviour as pixel precision wheel events to the specified positions in the WebWidget.

[Robert Kroeger]

Created attachment 67479 [details]
Patch for 45560: minor touch tweaks and gestureScroll method

[WebKit Review Bot]

Attachment 67479 [details] did not pass style-queue:

Failed to run "['WebKitTools/Scripts/check-webkit-style']" exit_code: 1
WebKit/chromium/tests/GestureScrollTest.cpp:33:  Found other header before a header this file implements. Should be: config.h, primary header, blank line, and then alphabetically sorted.  [build/include_order] [4]
WebKit/chromium/tests/GestureScrollTest.cpp:35:  Alphabetical sorting problem.  [build/include_order] [4]
WebKit/chromium/tests/GestureScrollTest.cpp:39:  Alphabetical sorting problem.  [build/include_order] [4]
WebKit/chromium/tests/GestureScrollTest.cpp:63:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
WebKit/chromium/tests/GestureScrollTest.cpp:64:  Missing space after ,  [whitespace/comma] [3]
WebKit/chromium/tests/GestureScrollTest.cpp:66:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
WebKit/chromium/tests/GestureScrollTest.cpp:78:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
WebKit/chromium/tests/GestureScrollTest.cpp:79:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
WebKit/chromium/tests/GestureScrollTest.cpp:81:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
WebKit/chromium/tests/GestureScrollTest.cpp:82:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
WebKit/chromium/tests/GestureScrollTest.cpp:83:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
WebKit/chromium/tests/GestureScrollTest.cpp:84:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
WebKit/chromium/tests/GestureScrollTest.cpp:85:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
WebKit/chromium/tests/GestureScrollTest.cpp:104:  Missing space after ,  [whitespace/comma] [3]
WebKit/chromium/tests/GestureScrollTest.cpp:105:  Missing space after ,  [whitespace/comma] [3]
WebKit/chromium/src/WebPopupMenuImpl.cpp:127:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Total errors found: 16 in 12 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Darin Fisher (:fishd, Google)]

Why do we want the logic for initiating scrolls outside of WebKit?

[Robert Kroeger]

(In reply to comment #3)
> Why do we want the logic for initiating scrolls outside of WebKit?

Various gestures may wish to initiate scrolling.  But I wanted to put the code for recognizing gestures in Chrome (as opposed to WebKit) to make it possible for both Views-based UI code and the RenderView to share as much of the gesture detection code as possible.

Adding this new entry point seemed to provide a clearer separation of concern than crafting and delivering fake mouse wheel events from the RenderView.

[Dimitri Glazkov (Google)]

(In reply to comment #4)
> (In reply to comment #3)
> > Why do we want the logic for initiating scrolls outside of WebKit?
> 
> Various gestures may wish to initiate scrolling.  But I wanted to put the code for recognizing gestures in Chrome (as opposed to WebKit) to make it possible for both Views-based UI code and the RenderView to share as much of the gesture detection code as possible.
> 
> Adding this new entry point seemed to provide a clearer separation of concern than crafting and delivering fake mouse wheel events from the RenderView.

Wouldn't it be a Good Thing to have this code in WebCore? It seems that sharing this code across various ports of WebKit is a more interesting idea than sharing it between parts of Chrome.

[Robert Kroeger]

Created attachment 67598 [details]
patch for 45560: fewer style warnings.

[WebKit Review Bot]

Attachment 67598 [details] did not pass style-queue:

Failed to run "['WebKitTools/Scripts/check-webkit-style']" exit_code: 1
WebKit/chromium/tests/GestureScrollTest.cpp:33:  Found other header before a header this file implements. Should be: config.h, primary header, blank line, and then alphabetically sorted.  [build/include_order] [4]
Total errors found: 1 in 12 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Dimitri Glazkov (Google)]

Comment on attachment 67598 [details]
patch for 45560: fewer style warnings.

The code is fine, but I really think we should bake GestureManager stuff into WebCore.

[Darin Fisher (:fishd, Google)]

Comment on attachment 67598 [details]
patch for 45560: fewer style warnings.

R- because I object to the addition of WebWidget::gestureScroll.

See the discussion here:
http://codereview.chromium.org/3388013

It seems like the GestureManager from that patch can move into WebKit so
that the interface for event processing in WebKit remains handleInputEvent.