New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 734092 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Support touch-like stylus in gpuBenchmarking.pointerActionSequence()

Project Member Reported by chongz@chromium.org, Jun 16 2017

Issue description

Currently the |source| of the action could be 'touch', 'mouse' or 'pen', and 'pen' will generate mouse events (similar to on Windows):
https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/synthetic_pen_driver.h?l=14

However on ChromeOS and Android a stylus will generate touch events and makes it hard to test the real behavior.

Possible solutions:
a. Use |eventSender| for touch-like / mouse-like stylus sensitive tests for now, and make 'pen' generate touch events once we have unified platforms.
  * |eventSender| tests won't go through gesture recognizer.

b. 'pen' should generate mouse or touch events based on the platform.
  * Cons: The platform difference may cause some confusion when writing tests.

c. Add an API to specify the behavior of 'pen'.
  * Cons: I'm not sure if it worth the effort as our ultimate goal should be an unified behavior.

Maybe b. is better?
 
Do we have a platform that generates touch events for a hovering pen?
So at the end I believe we will have two types of pen inputs and the need to extend the pointerActionSequence API is inevitable? WTYD?

Comment 2 by mustaq@chromium.org, Jun 16 2017

Yeah, seems like it unfortunately.

Since most platforms are using/switching to touch-like pens (without hovering support of course), I still hope the split behavior will be gone one day, perhaps this could force extending ui-level touch events to support hover.

Comment 3 by chongz@chromium.org, Jun 16 2017

Sorry for the confusion, to be more specific I'm concerned about the situation where the same user action could ended up with different events based on the platform.
e.g. Click with a stylus.

And the |pointerActionSequence| API should be able to test this behavior.

---
The mix of mouse/touch events are fine WRT this issue as long as the same user action maps to the same set of events.

e.g. For hovering pen I assume we could add something like "pointerHover" action to generate mouse events?
I believe the easier way and more inline with the current design is adding a new pointerType rather than a new action. So that if you use |pointerActionSequence| with pointerType="hovering-pen" then it would send the event through mouse code path and if you use it with pointerType="pen" then it would send it through touch code path. Lan, WDYT?

Comment 5 by chongz@chromium.org, Jun 19 2017

Ok, just want to confirm, does it mean we will have 3 "pen"-like pointer types:
1. "pen" (current, Windows-like)
  * Move: 'mousemove'
  * Click: 'mousedown' => 'mouseup' => 'click'
2. "touch-pen" (ChromeOS and Android-like)
  * Move: 'touchstart', 'touchevend', etc.
  * Click: 'touchstart' => 'touchevend' => 'gesturetap' => 'mousedown' => 'mouseup' => 'click'
3. "hovering-pen"
  * Move: 'mousemove' with hover state
  * Click: (Similar to "pen"? I'm not sure but can click with a hovering pen?)

Comment 6 by chongz@chromium.org, Jun 19 2017

Discussed with nzolghadr@, lanwei@ offline and it seems that option c. would be more preferable as we can choose which path we want to test.

dtapuska@ Are you OK with adding pointerType "touch-pen" or do you still prefer option b.?

Comment 7 by chongz@chromium.org, Jan 11 2018

Cc: chongz@chromium.org
Owner: ----
Status: Available (was: Assigned)
Mark as available so somebody else can pick up :)
Project Member

Comment 8 by sheriffbot@chromium.org, Jan 14

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 9 by nzolghadr@google.com, Jan 17 (6 days ago)

Status: Available (was: Untriaged)
Still an issue in 2019 Q1 check in.

Sign in to add a comment