RESOLVED WONTFIX 88440
[chromium] cancel flings on receipt of MouseWheel events
https://bugs.webkit.org/show_bug.cgi?id=88440
Summary [chromium] cancel flings on receipt of MouseWheel events
Robert Kroeger
Reported 2012-06-06 11:59:57 PDT
Permit the browser to reduce the number of GestureFlingCancel events it sends to WebKit by also stopping an in-progress fling on WheelEvent arrival.
Attachments
Patch (4.40 KB, patch)
2012-06-06 14:54 PDT, Robert Kroeger
no flags
Archive of layout-test-results from ec2-cr-linux-04 (571.57 KB, application/zip)
2012-06-06 23:52 PDT, WebKit Review Bot
no flags
Patch (4.19 KB, patch)
2012-06-08 10:18 PDT, Robert Kroeger
no flags
Patch (1.36 KB, patch)
2012-06-08 10:36 PDT, Robert Kroeger
no flags
Patch (11.85 KB, patch)
2012-06-11 14:15 PDT, Robert Kroeger
no flags
Patch (5.39 KB, patch)
2012-06-11 14:17 PDT, Robert Kroeger
jamesr: review-
Robert Kroeger
Comment 1 2012-06-06 14:54:52 PDT
WebKit Review Bot
Comment 2 2012-06-06 23:52:21 PDT
Comment on attachment 146117 [details] Patch Attachment 146117 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12907534 New failing tests: WebCompositorInputHandlerImplTest.gestureFlingAnimates WebCompositorInputHandlerImplTest.gestureFlingTransferResets
WebKit Review Bot
Comment 3 2012-06-06 23:52:25 PDT
Created attachment 146211 [details] Archive of layout-test-results from ec2-cr-linux-04 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-04 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Robert Kroeger
Comment 4 2012-06-08 10:18:53 PDT
Robert Kroeger
Comment 5 2012-06-08 10:36:49 PDT
Robert Kroeger
Comment 6 2012-06-11 14:15:14 PDT
Robert Kroeger
Comment 7 2012-06-11 14:17:49 PDT
Robert Kroeger
Comment 8 2012-06-11 14:20:00 PDT
jamesr@ mind taking a look please?
WebKit Review Bot
Comment 9 2012-06-11 14:23:16 PDT
Attachment 146908 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebKit/chromium/ChangeLog', u'Sourc..." exit_code: 1 Source/WebKit/chromium/src/WebCompositorInputHandlerImpl.cpp:164: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] Total errors found: 1 in 7 files If any of these errors are false positives, please file a bug against check-webkit-style.
James Robinson
Comment 10 2012-06-11 14:32:30 PDT
What's the motivation for putting this logic inside WebKit instead of in the embedder?
Robert Kroeger
Comment 11 2012-06-11 14:52:19 PDT
Why in WebKit and not in the browser: the knowledge that a fling is in progress (i.e. there is a curve) is in WebKit.
James Robinson
Comment 12 2012-06-11 15:48:48 PDT
Yes, but WebKit only knows about a subset of the interactions the user is having with the system. For instance, if a user switches tabs using a keyboard accelerator I would expect that the fling should be cancelled and that WebKit would not necessarily see any of the key events associated with that interaction (since they would be handled browser-side). In this case we couldn't really cancel the fling from within WebKit unless we taught WebKit about all of the possible side-effects of fling cancelling interactions.
James Robinson
Comment 13 2012-06-11 15:49:27 PDT
Comment on attachment 146908 [details] Patch Seems like the wrong direction.
James Robinson
Comment 14 2012-06-11 15:52:40 PDT
Also the browser always knows if it's sent a fling start to WebKit, the only thing the browser does not know is whether that fling has ended "naturally" or needs to be explicitly cancelled. I think sending a cancelFlingIfInProgress is quite reasonable for the case where the browser doesn't know this information.
Note You need to log in before you can comment on or make changes to this bug.