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

Issue metadata

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

Blocked on:
issue 313353


Show other hotlists

Hotlists containing this issue:
Nice-to-haves-for-Project-V


Sign in to add a comment

Immediately show hover and active states on touch when page isn't scrollable.

Project Member Reported by tdres...@chromium.org, Oct 11 2013

Issue description

Currently Blink uses the show press gesture to determine when to display hover and active states. If a page isn't scrollable, we should use the tap down gesture, and avoid the delay associated with show press.

Note - we don't want to use touch start here, as we'd lose touch fuzzing.
 

Comment 1 by rbyers@chromium.org, Oct 24 2013

Labels: -Cr-UI-Input-Touch-Screen Cr-Internals-Input-Touch-Screen

Comment 2 by rbyers@chromium.org, Oct 24 2013

Cc: tdres...@chromium.org
Labels: M-33
Owner: zeeshanq@chromium.org
Sounds like there is support for this idea from Google webdevs.  Let's try to make it happen in M33.
Blockedon: chromium:302752
Blocked on Tap Down events being sent correctly.
This is in code review here: https://codereview.chromium.org/40913002/.
Blockedon: -chromium:302752
Unblocked.
Is this sent for pinch?
Good point - we probably wouldn't want to risk adding any jank / flicker to the start of a pinch.  TapDown would be sent for pinch (all the time on Aura since we get each finger as an independent event, and presumably at least fairly often on Android).

So maybe we should do this only in cases when both scrolling and pinching are impossible.  Thoughts?
Currently, the tap down and show press gestures are sent when a single finger performs a press.

The renderer will decide whether to apply the :active state on touch down or show press based on whether or not the page can be scrolled (or pinched).

I believe that any page which can be scrolled can also be pinched, and vice versa.


There are cases where scrolling is impossible until a user pinches, but I'm not sure how relevant that is here.
Right, we do want to only use the tap down event when a page can't be scrolled or pinched.
How are you going to detect "page can't be scrolled"? Presumably what you precisely mean is "this tap down couldn't possibly be the start of a scroll gesture", hence you'll walk up the tree from the hit point and check if there are any iframes, overflow:scroll divs, etc?
We need "this tap down couldn't possibly be the start of a scroll or pinch gesture".
This will involve walking up the tree from the hit point as you describe.
TapDown should be as cheap an event as possible.  We should resolve the layout/autosizing issues from https://code.google.com/p/chromium/issues/detail?id=313353 before we consider a change like this (if indeed that issue is related to this proposal).
Blockedon: chromium:313353
Yes, TapDown shouldn't generally be triggering layout.  So definitely let's make sure  issue 313353  is understood.  But regardless the main reason we want tapDown to be cheap is that we might start scrolling, and we don't want to block that.  If scrolling/pinching isn't possible, then potentially doing a more expensive style recalc / layout is probably OK (and really want we want for the sake of responsiveness).
Labels: -M-33 M-34
Cc: bokan@chromium.org
Labels: -Cr-Internals-Input-Touch-Screen -M-34 Cr-Blink-Input M-35 Iteration-100
Status: Started
Labels: -M-35 M-36
Labels: Iteration-102
This has somewhat stalled in code review - debate on whether we really want it or not.  See https://codereview.chromium.org/163933002/

Comment 20 by jdduke@google.com, May 1 2014

Somewhat related, we had an offline discussion about reducing the ShowPress timeout delay on Android to 100ms, to which I didn't see any immediate objections. 

Comment 21 by meh@chromium.org, May 5 2014

Labels: Hotlist-Input-Dev
Labels: -M-36 M-37 MovedFrom-36
Moving all non essential bugs to the next Milestone.
Labels: -M-37 MovedFrom-37
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
Status: WontFix
Cc: zeeshanq@chromium.org
Labels: -Iteration-100 -Iteration-102 -MovedFrom-36 -MovedFrom-37
Owner: rbyers@chromium.org
Status: Assigned
I personally think we still want this eventually.  Let's park it on me for now.
Cc: -zeeshanq@chromium.org
Owner: ----
Status: Available (was: Assigned)
Project Member

Comment 28 by sheriffbot@chromium.org, Jul 3 2017

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. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Pri-2 Pri-3
Status: Available (was: Untriaged)
Note that trying to standardize this whole space is tracked in https://github.com/w3c/pointerevents/issues/123

Sign in to add a comment