Bug 96948

Summary: [chromium] Enable shouldGesturesTriggerActive for Android
Product: WebKit Reporter: Rick Byers <rbyers>
Component: UI EventsAssignee: yusufo
Status: RESOLVED FIXED    
Severity: Normal CC: aelias, jamesr, klobag, leviw, rbyers, skyostil, webkit.review.bot, yusufo
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch none

Rick Byers
Reported 2012-09-17 13:08:29 PDT
In https://bugs.webkit.org/show_bug.cgi?id=96060 chromium got support for triggering the 'active' state via gesture events. This is disabled on Android for now due to lack of GestureTapCancel support in the gesture recognizer there. Once it's added and plumbed into WebKit, shouldGesturesTriggerActive in EventHandler.cpp should be updated to enable the support in Android as well.
Attachments
Patch (1.52 KB, patch)
2012-12-13 14:17 PST, yusufo
no flags
Patch (1.61 KB, patch)
2013-02-05 13:18 PST, yusufo
no flags
Rick Byers
Comment 1 2012-11-05 07:32:56 PST
Note that this will fix the performance problem with touchstart triggering hover/active states (makes the touchstart hit-test a readonly test).
yusufo
Comment 2 2012-12-13 14:17:27 PST
Rick Byers
Comment 3 2012-12-13 15:42:28 PST
Have you already done the work elsewhere to send GestureTapCancel such that TapDown is always followed by either Tap or TapCancel? It was the lack of any GestureTapCancel event that led me to have this be disabled on Android.
yusufo
Comment 4 2012-12-13 15:52:05 PST
(In reply to comment #3) > Have you already done the work elsewhere to send GestureTapCancel such that TapDown is always followed by either Tap or TapCancel? It was the lack of any GestureTapCancel event that led me to have this be disabled on Android. In gesture_event_filter, we have added gestureLongPress and gestureDoubleTap to the gestures that can follow a gestureTapDown. So right now TapDown is always folled by Tap, DoubleTap or DoubleTap for us. I think it is still OK even if we don't introduce TapCancel, right?
Rick Byers
Comment 5 2012-12-13 16:00:41 PST
No, I don't think that's enough. EventHandler::handleGestureEvent assumes that TapDown is followed by either a Tap or TapCancel. Otherwise you may find 'active' states getting stuck on (i.e. a missing Release hit test). We thought about just looking for some set of specific events rather than introducing TapCancel, but we decided that would be too brittle - different platforms may have different events that follow and it's a pain to update them. So figured it was better to require the platform to explicitly tell us when a Tap is no longer possible.
James Robinson
Comment 6 2012-12-14 11:18:56 PST
Comment on attachment 179331 [details] Patch R- for now based on rbyer's comments that this won't work yet
yusufo
Comment 7 2013-02-05 10:40:29 PST
Comment on attachment 179331 [details] Patch We have landed all the changes necessary to handle this properly on Android. All TapDown are followed by a Tap or TapCancel right now.
James Robinson
Comment 8 2013-02-05 10:49:15 PST
Comment on attachment 179331 [details] Patch Any way to test this?
yusufo
Comment 9 2013-02-05 10:55:04 PST
I think the original bug that introduced this change https://bugs.webkit.org/show_bug.cgi?id=96060 has the related tests. I will verify that those tests are running for us and then flip the cq flag.
yusufo
Comment 10 2013-02-05 11:23:48 PST
Comment on attachment 179331 [details] Patch Verified that these tests are not disabled for us in TestExpectations chromium and chromium-android. After the change they should start running with the right behavior.
WebKit Review Bot
Comment 11 2013-02-05 12:03:24 PST
Comment on attachment 179331 [details] Patch Rejecting attachment 179331 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=gce-cq-04', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 179331, '--port=chromium-xvfb']" exit_code: 2 cwd: /mnt/git/webkit-commit-queue Last 500 characters of output: t/git/webkit-commit-queue/Source/WebKit/chromium/v8 --revision 13563 --non-interactive --force --accept theirs-conflict --ignore-externals' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' 53>At revision 13563. ________ running '/usr/bin/python tools/clang/scripts/update.py --mac-only' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' ________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' Updating webkit projects from gyp files... Full output: http://queues.webkit.org/results/16365947
yusufo
Comment 12 2013-02-05 13:18:25 PST
yusufo
Comment 13 2013-02-05 13:20:16 PST
Sorry, it looks I had to fix the Changelog. Fixed it and added the test related info on the Changelog. Can you review again and push it to CQ if it looks good?
WebKit Review Bot
Comment 14 2013-02-05 14:06:09 PST
Comment on attachment 186690 [details] Patch Clearing flags on attachment: 186690 Committed r141929: <http://trac.webkit.org/changeset/141929>
WebKit Review Bot
Comment 15 2013-02-05 14:06:14 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.