|
|
Created:
3 years, 7 months ago by David Tseng Modified:
3 years, 6 months ago CC:
chromium-reviews, kalyank, sadrul, oshima+watch_chromium.org Target Ref:
refs/heads/master Project:
chromium Visibility:
Public. |
DescriptionImplement touch exploration touch typing
The functional change occurs for the following two event sequences. Each results in a synthesized tap at the anchor point.
Single finger tap:
Function name: InNoFingersDown
State: SINGLE_TAP_PRESSED
Function name: InSingleTapPressed
State: SINGLE_TAP_RELEASED
Function name: OnTapTimerFired
State: NO_FINGERS_DOWN
Touch exploration lift:
Function name: InNoFingersDown
State: SINGLE_TAP_PRESSED
Function name: InSingleTapPressed
State: GESTURE_IN_PROGRESS
Function name: OnTapTimerFired
State: TOUCH_EXPLORATION
Function name: InTouchExploration
State: TOUCH_EXPLORE_RELEASED
Function name: OnTapTimerFired
State: NO_FINGERS_DOWN
TEST=ui_chromeos_unittests --gtest_filter=TouchExplore*.*
BUG=670894
Review-Url: https://codereview.chromium.org/2880043002
Cr-Commit-Position: refs/heads/master@{#475650}
Committed: https://chromium.googlesource.com/chromium/src/+/64b2d8e9fedef8add46fef50558ebb0cca831232
Patch Set 1 #
Total comments: 6
Patch Set 2 : Address feedback. #
Total comments: 2
Patch Set 3 : Nits. #
Total comments: 3
Patch Set 4 : Remove observer. #
Total comments: 4
Patch Set 5 : Use ShellObserver. #
Total comments: 12
Patch Set 6 : Add comments. #
Messages
Total messages: 54 (30 generated)
dtseng@chromium.org changed reviewers: + dmazzoni@chromium.org
PTAL. Note that I tried a few different approaches and this turned out to be the simplest and cleanest.
The CQ bit was checked by dtseng@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
No objections to this approach in general. A unittest in touch_exploration_controller_unittest.cc would be good. https://codereview.chromium.org/2880043002/diff/1/ui/chromeos/touch_explorati... File ui/chromeos/touch_exploration_controller.cc (right): https://codereview.chromium.org/2880043002/diff/1/ui/chromeos/touch_explorati... ui/chromeos/touch_exploration_controller.cc:485: DispatchSynthesizedTap(); I think you'll want to call it from more than one state than this. For example a quick tap without first entering touch exploration should work too. How about intercepting the code that sends a hover event and have it send a click event instead? https://codereview.chromium.org/2880043002/diff/1/ui/chromeos/touch_explorati... ui/chromeos/touch_exploration_controller.cc:661: void TouchExplorationController::DispatchSynthesizedTap() { Rather than splitting SendSimulatedClick into two pieces, maybe you could just handle the anchor point - like not setting an anchor point if it's within the lift activation bounds? Or figure out why sending AX_GESTURE_CLICK doesn't work https://codereview.chromium.org/2880043002/diff/1/ui/chromeos/touch_explorati... ui/chromeos/touch_exploration_controller.cc:821: std::unique_ptr<ui::Event> mouse_move = CreateMouseMoveEvent( Here's the other place where you'll want to send a simulated click in lift to touch mode, unless you want to not even set a tap timer.
Responding to click comment. If agreed not to use click, I'll write some tests for the current tap simulation. https://codereview.chromium.org/2880043002/diff/1/ui/chromeos/touch_explorati... File ui/chromeos/touch_exploration_controller.cc (right): https://codereview.chromium.org/2880043002/diff/1/ui/chromeos/touch_explorati... ui/chromeos/touch_exploration_controller.cc:485: DispatchSynthesizedTap(); On 2017/05/15 21:24:34, dmazzoni wrote: > I think you'll want to call it from more than one state > than this. For example a quick tap without first > entering touch exploration should work too. > > How about intercepting the code that sends a hover > event and have it send a click event instead? > > Sending a click event maps to forceClickOnCurrentItem in ChromeVox which calls doDefault (accessibility action). Do default is not a click in Blink (as I found out) but it is simply calling through to a node's access key action which in most cases is like a click. However, for bare bones div's and even things with aria roles, this won't work. That's why ChromeVox + space wasn't working when I was showing you the other day. We can dispatch a raw click event, but that is generally not the direction we want to go as with context menus, sending click events can be tricky e.g. nodes in z-coord ordering hiding other nodes. https://codereview.chromium.org/2880043002/diff/1/ui/chromeos/touch_explorati... ui/chromeos/touch_exploration_controller.cc:485: DispatchSynthesizedTap(); On 2017/05/15 21:24:34, dmazzoni wrote: > I think you'll want to call it from more than one state > than this. For example a quick tap without first > entering touch exploration should work too. > > How about intercepting the code that sends a hover > event and have it send a click event instead? > > Isn't a quick tap just pass through mode? i.e. it achieves the same thing. https://codereview.chromium.org/2880043002/diff/1/ui/chromeos/touch_explorati... ui/chromeos/touch_exploration_controller.cc:661: void TouchExplorationController::DispatchSynthesizedTap() { On 2017/05/15 21:24:35, dmazzoni wrote: > Rather than splitting SendSimulatedClick into two > pieces, maybe you could just handle the anchor point - > like not setting an anchor point if it's within the > lift activation bounds? Or figure out why sending > AX_GESTURE_CLICK doesn't work Ditto.
On Tue, May 16, 2017 at 9:07 AM <dtseng@chromium.org> wrote: > > I think you'll want to call it from more than one state > > than this. For example a quick tap without first > > entering touch exploration should work too. > > > > How about intercepting the code that sends a hover > > event and have it send a click event instead? > > Sending a click event maps to forceClickOnCurrentItem in ChromeVox which > calls > doDefault (accessibility action). > > Do default is not a click in Blink (as I found out) but it is simply > calling through to a node's access key action which in most cases is > like a click. > > However, for bare bones div's and even things with aria roles, this > won't work. That's why ChromeVox + space wasn't working when I was > showing you the other day. > Oh interesting, I didn't realize that the access key action code didn't do a simulated click as a fallback. Perhaps it should. -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
As discussed in person, just make the distinction between SendSimulatedClick and DispatchSimulatedTap more clear, and make sure to handle the case of a quick tap-and-release (before it enters touch exploration mode) and then it should be good
Description was changed from ========== Implement touch exploration touch typing TEST=manual. BUG= ========== to ========== Implement touch exploration touch typing The functional change occurs for the following two event sequences. Each results in a synthesized tap at the anchor point. Single finger tap: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: SINGLE_TAP_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN Touch exploration lift: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: GESTURE_IN_PROGRESS Function name: OnTapTimerFired State: TOUCH_EXPLORATION Function name: InTouchExploration State: TOUCH_EXPLORE_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN TEST=ui_chromeos_unittests --gtest_filter=TouchExplore*.* BUG= ==========
PTAL. Added tests for both cases; note that the quick single finger tap case is pretty hard to trigger (without having knowledge of the exact location). Might want to revisit that particular state in the future.
The CQ bit was checked by dtseng@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Implement touch exploration touch typing The functional change occurs for the following two event sequences. Each results in a synthesized tap at the anchor point. Single finger tap: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: SINGLE_TAP_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN Touch exploration lift: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: GESTURE_IN_PROGRESS Function name: OnTapTimerFired State: TOUCH_EXPLORATION Function name: InTouchExploration State: TOUCH_EXPLORE_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN TEST=ui_chromeos_unittests --gtest_filter=TouchExplore*.* BUG= ========== to ========== Implement touch exploration touch typing The functional change occurs for the following two event sequences. Each results in a synthesized tap at the anchor point. Single finger tap: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: SINGLE_TAP_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN Touch exploration lift: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: GESTURE_IN_PROGRESS Function name: OnTapTimerFired State: TOUCH_EXPLORATION Function name: InTouchExploration State: TOUCH_EXPLORE_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN TEST=ui_chromeos_unittests --gtest_filter=TouchExplore*.* BUG=670894 ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Friendly ping; would like to get this in for m60 before branch.
lgtm Tests look great! https://codereview.chromium.org/2880043002/diff/20001/ui/chromeos/touch_explo... File ui/chromeos/touch_exploration_controller_unittest.cc (right): https://codereview.chromium.org/2880043002/diff/20001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller_unittest.cc:1987: TEST_F(TouchExplorationTest, SingleTapInActivationArea) { Maybe ...InLiftActivationArea to be clear?
https://codereview.chromium.org/2880043002/diff/20001/ui/chromeos/touch_explo... File ui/chromeos/touch_exploration_controller_unittest.cc (right): https://codereview.chromium.org/2880043002/diff/20001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller_unittest.cc:1987: TEST_F(TouchExplorationTest, SingleTapInActivationArea) { On 2017/05/19 19:44:49, dmazzoni wrote: > Maybe ...InLiftActivationArea to be clear? Done.
dtseng@chromium.org changed reviewers: + oshima@chromium.org
+ oshima for ash/
dtseng@chromium.org changed reviewers: + derat@chromium.org - oshima@chromium.org
+ derat for ash/.
oshima@chromium.org changed reviewers: + oshima@chromium.org
https://codereview.chromium.org/2880043002/diff/40001/ash/ash_touch_explorati... File ash/ash_touch_exploration_manager_chromeos.cc (right): https://codereview.chromium.org/2880043002/diff/40001/ash/ash_touch_explorati... ash/ash_touch_exploration_manager_chromeos.cc:195: keyboard_controller->AddObserver(this); don't you have to remove it later?
https://codereview.chromium.org/2880043002/diff/40001/ash/ash_touch_explorati... File ash/ash_touch_exploration_manager_chromeos.cc (right): https://codereview.chromium.org/2880043002/diff/40001/ash/ash_touch_explorati... ash/ash_touch_exploration_manager_chromeos.cc:195: keyboard_controller->AddObserver(this); On 2017/05/25 23:31:58, oshima wrote: > don't you have to remove it later? base::ScopedObserver is a good way to avoid bugs like this.
https://codereview.chromium.org/2880043002/diff/40001/ash/ash_touch_explorati... File ash/ash_touch_exploration_manager_chromeos.cc (right): https://codereview.chromium.org/2880043002/diff/40001/ash/ash_touch_explorati... ash/ash_touch_exploration_manager_chromeos.cc:195: keyboard_controller->AddObserver(this); On 2017/05/25 23:31:58, oshima wrote: > don't you have to remove it later? Done.
The CQ bit was checked by dtseng@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
On 2017/05/26 16:05:15, David Tseng wrote: > https://codereview.chromium.org/2880043002/diff/40001/ash/ash_touch_explorati... > File ash/ash_touch_exploration_manager_chromeos.cc (right): > > https://codereview.chromium.org/2880043002/diff/40001/ash/ash_touch_explorati... > ash/ash_touch_exploration_manager_chromeos.cc:195: > keyboard_controller->AddObserver(this); > On 2017/05/25 23:31:58, oshima wrote: > > don't you have to remove it later? > > Done. Can you use base::ScopedObserver as Dan suggested?
https://codereview.chromium.org/2880043002/diff/60001/ash/ash_touch_explorati... File ash/ash_touch_exploration_manager_chromeos.cc (right): https://codereview.chromium.org/2880043002/diff/60001/ash/ash_touch_explorati... ash/ash_touch_exploration_manager_chromeos.cc:43: keyboard_controller->RemoveObserver(this); yes, please use ScopedObserver. this is still wrong, as the observer is removed in the d'tor but not added in the c'tor, i.e. you'll remove without having added earlier if UpdateTouchExplorationState isn't called before destruction.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/2880043002/diff/60001/ash/ash_touch_explorati... File ash/ash_touch_exploration_manager_chromeos.cc (right): https://codereview.chromium.org/2880043002/diff/60001/ash/ash_touch_explorati... ash/ash_touch_exploration_manager_chromeos.cc:43: keyboard_controller->RemoveObserver(this); On 2017/05/26 16:33:38, Daniel Erat wrote: > yes, please use ScopedObserver. this is still wrong, as the observer is removed > in the d'tor but not added in the c'tor, i.e. you'll remove without having added > earlier if UpdateTouchExplorationState isn't called before destruction. Sorry, I must be mistaken, but removing if not previously added is a no-op, right, so why does this matter? The larger issue here is that the keyboard controller gets re-initialized on session state changed, so though the keyboard controller looks like a singleton, it's not and AshTouchExplorationManager has a slightly longer lifetime than KeyboardControllers. It's not entirely clear to me what the relationship between AshTouchExplorationManager (which is owned by RootWindowController) and KeyboardController should be.
https://codereview.chromium.org/2880043002/diff/60001/ash/ash_touch_explorati... File ash/ash_touch_exploration_manager_chromeos.cc (right): https://codereview.chromium.org/2880043002/diff/60001/ash/ash_touch_explorati... ash/ash_touch_exploration_manager_chromeos.cc:43: keyboard_controller->RemoveObserver(this); On 2017/05/26 21:13:47, David Tseng wrote: > On 2017/05/26 16:33:38, Daniel Erat wrote: > > yes, please use ScopedObserver. this is still wrong, as the observer is > removed > > in the d'tor but not added in the c'tor, i.e. you'll remove without having > added > > earlier if UpdateTouchExplorationState isn't called before destruction. > > Sorry, I must be mistaken, but removing if not previously added is a no-op, > right, so why does this matter? > > The larger issue here is that the keyboard controller gets re-initialized on > session state changed, so though the keyboard controller looks like a singleton, > it's not and AshTouchExplorationManager has a slightly longer lifetime than > KeyboardControllers. > > It's not entirely clear to me what the relationship between > AshTouchExplorationManager (which is owned by RootWindowController) and > KeyboardController should be. it's standard practice in chrome to keep track of whether you've added an observer and remove it iff it's been added. you can't double-add, for instance: https://chromium.googlesource.com/chromium/src/+/master/base/observer_list.h#276 i didn't realize that the KeyboardController is reinitialized. do you have some way to register to be notified when it's destroyed? (does it have an OnDestroying() method in its observer class?)
PTAL. https://codereview.chromium.org/2880043002/diff/60001/ash/ash_touch_explorati... File ash/ash_touch_exploration_manager_chromeos.cc (right): https://codereview.chromium.org/2880043002/diff/60001/ash/ash_touch_explorati... ash/ash_touch_exploration_manager_chromeos.cc:43: keyboard_controller->RemoveObserver(this); On 2017/05/26 21:37:23, Daniel Erat wrote: > On 2017/05/26 21:13:47, David Tseng wrote: > > On 2017/05/26 16:33:38, Daniel Erat wrote: > > > yes, please use ScopedObserver. this is still wrong, as the observer is > > removed > > > in the d'tor but not added in the c'tor, i.e. you'll remove without having > > added > > > earlier if UpdateTouchExplorationState isn't called before destruction. > > > > Sorry, I must be mistaken, but removing if not previously added is a no-op, > > right, so why does this matter? > > > > The larger issue here is that the keyboard controller gets re-initialized on > > session state changed, so though the keyboard controller looks like a > singleton, > > it's not and AshTouchExplorationManager has a slightly longer lifetime than > > KeyboardControllers. > > > > It's not entirely clear to me what the relationship between > > AshTouchExplorationManager (which is owned by RootWindowController) and > > KeyboardController should be. > > it's standard practice in chrome to keep track of whether you've added an > observer and remove it iff it's been added. you can't double-add, for instance: > https://chromium.googlesource.com/chromium/src/+/master/base/observer_list.h#276 > > i didn't realize that the KeyboardController is reinitialized. do you have some > way to register to be notified when it's destroyed? (does it have an > OnDestroying() method in its observer class?) Sort of (indirectly through ShellObserver). There is some precedence for an object wanting to observe keyboard changes (see ShelfLayoutManager). I've added similar support in AshTouchExplorationManager.
The CQ bit was checked by dtseng@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... File ui/chromeos/touch_exploration_controller.h (right): https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller.h:197: // For touch explore release state that fall within |bounds|, causes a tap to nit: s/state/states/ https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller.h:198: // be synthesized and dispatched to the anchor point. this comment seems a bit misleading, since this method just saves the bounds and doesn't actually dispatch the tap, right? would something like this be more accurate? // Updates |lift_activation_bounds_| so that _____ (insert method // name here) can later synthesize and dispatch a tap to the anchor // point if the touch exploration release state falls within |bounds|. https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller.h:303: void SendSimulatedClickOrTap(); please add comments above these methods documenting what they do. in particular, please document how this method decides between clicks and taps, and how MaybeSend... determines whether it should send the tap or not. https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller.h:523: gfx::Rect lift_activation_bounds_; add a comment documenting what this contains https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... File ui/chromeos/touch_exploration_controller_unittest.cc (right): https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller_unittest.cc:1990: gfx::Rect window = BoundsOfRootWindowInDIP(); you don't use this variable later, so just call BoundsOf... on the next line https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller_unittest.cc:2028: gfx::Rect window = BoundsOfRootWindowInDIP(); see above
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... File ui/chromeos/touch_exploration_controller.h (right): https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller.h:197: // For touch explore release state that fall within |bounds|, causes a tap to On 2017/05/30 17:15:50, Daniel Erat wrote: > nit: s/state/states/ Done. https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller.h:198: // be synthesized and dispatched to the anchor point. On 2017/05/30 17:15:50, Daniel Erat wrote: > this comment seems a bit misleading, since this method just saves the bounds and > doesn't actually dispatch the tap, right? > > would something like this be more accurate? > > // Updates |lift_activation_bounds_| so that _____ (insert method > // name here) can later synthesize and dispatch a tap to the anchor > // point if the touch exploration release state falls within |bounds|. Done. https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller.h:303: void SendSimulatedClickOrTap(); On 2017/05/30 17:15:50, Daniel Erat wrote: > please add comments above these methods documenting what they do. in particular, > please document how this method decides between clicks and taps, and how > MaybeSend... determines whether it should send the tap or not. Done. https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller.h:523: gfx::Rect lift_activation_bounds_; On 2017/05/30 17:15:50, Daniel Erat wrote: > add a comment documenting what this contains Done. https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... File ui/chromeos/touch_exploration_controller_unittest.cc (right): https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller_unittest.cc:1990: gfx::Rect window = BoundsOfRootWindowInDIP(); On 2017/05/30 17:15:50, Daniel Erat wrote: > you don't use this variable later, so just call BoundsOf... on the next line Done. https://codereview.chromium.org/2880043002/diff/80001/ui/chromeos/touch_explo... ui/chromeos/touch_exploration_controller_unittest.cc:2028: gfx::Rect window = BoundsOfRootWindowInDIP(); On 2017/05/30 17:15:51, Daniel Erat wrote: > see above Done.
The CQ bit was checked by dtseng@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm
The CQ bit was checked by dtseng@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from dmazzoni@chromium.org Link to the patchset: https://codereview.chromium.org/2880043002/#ps100001 (title: "Add comments.")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 100001, "attempt_start_ts": 1496174965990430, "parent_rev": "fc8c7f3440cecb52667340276ea06100e303d4df", "commit_rev": "64b2d8e9fedef8add46fef50558ebb0cca831232"}
Message was sent while issue was closed.
Description was changed from ========== Implement touch exploration touch typing The functional change occurs for the following two event sequences. Each results in a synthesized tap at the anchor point. Single finger tap: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: SINGLE_TAP_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN Touch exploration lift: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: GESTURE_IN_PROGRESS Function name: OnTapTimerFired State: TOUCH_EXPLORATION Function name: InTouchExploration State: TOUCH_EXPLORE_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN TEST=ui_chromeos_unittests --gtest_filter=TouchExplore*.* BUG=670894 ========== to ========== Implement touch exploration touch typing The functional change occurs for the following two event sequences. Each results in a synthesized tap at the anchor point. Single finger tap: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: SINGLE_TAP_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN Touch exploration lift: Function name: InNoFingersDown State: SINGLE_TAP_PRESSED Function name: InSingleTapPressed State: GESTURE_IN_PROGRESS Function name: OnTapTimerFired State: TOUCH_EXPLORATION Function name: InTouchExploration State: TOUCH_EXPLORE_RELEASED Function name: OnTapTimerFired State: NO_FINGERS_DOWN TEST=ui_chromeos_unittests --gtest_filter=TouchExplore*.* BUG=670894 Review-Url: https://codereview.chromium.org/2880043002 Cr-Commit-Position: refs/heads/master@{#475650} Committed: https://chromium.googlesource.com/chromium/src/+/64b2d8e9fedef8add46fef50558e... ==========
Message was sent while issue was closed.
Committed patchset #6 (id:100001) as https://chromium.googlesource.com/chromium/src/+/64b2d8e9fedef8add46fef50558e... |