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

Issue 719456 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 418188
Owner: ----
Closed: Nov 29
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

:hover:active CSS state is not applied with touchmove

Reported by jeromin....@gmail.com, May 8 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3088.4 Safari/537.36

Steps to reproduce the problem:
1. Define an element with :hover:active pseudo class
2. Select the element with the mouse/finger
3. move the pointer inside the element

What is the expected behavior?
With touch interaction the style should be the same as with a mouse.
MouseDown: :hover:active is applied
MouseMove (inside element) :hover:active is STILL applied

What went wrong?
touchstart: :hover:active is applied
touchmove (inside element) :hover:active is NOT applied

Works with Firefox Mobile on Android.

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 60.0.3088.4  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
 
chrome_hoverActive_touch.html
457 bytes View Download

Comment 1 by shend@chromium.org, May 9 2017

Labels: Needs-Bisect
Status: Untriaged (was: Unconfirmed)
Repros on 60.0.3088.3 (Official Build) dev (64-bit) with devtools emulation.
Cc: sureshkumari@chromium.org
Labels: -Type-Bug -Pri-2 -Needs-Bisect hasbisect-per-revision M-60 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: yoichio@chromium.org
Status: Assigned (was: Untriaged)
Able to reproduce the issue on Windows-7,Mac-10.12.4 and Linux Ubuntu-14.04 using chrome stable version 58.0.3029.110 and canary 60.0.3095.0 with the steps provided in comment#0.This is regression issue,broken in M54.

Using the per-revision bisect providing the bisect results,
Good build:54.0.2832.0 (Revision:412743).
Bad build: 54.0.2833.0 (Revision:413134).
CHANGE-LOG URL:
https://chromium.googlesource.com/chromium/src/+log/95d59afa4ed0d1bc8b9a833e53377389608e81fd..a664cb352ef4e15f7e02ddfe2caae2c6d243a343

Review-Url: https://codereview.chromium.org/2246293003
yoichio@ Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change.

Thanks.!
Labels: Update-Quarterly
Labels: -Update-Quarterly qu
Owner: ----
My change is to support user-select in addition to -webkit-user-select so
 pages only use user-select change its behavior, of course. This is not regression.
Anyway this is interop issue on CSS.
Labels: -qu Update-Quarterly

Comment 6 by suzyh@chromium.org, May 16 2017

Labels: -Type-Bug-Regression Type-Bug
Per #4, moving this from Type=Bug-Regression to Type=Bug
I just found: 
Chrome has the same effect when interacting with the right mousebutton. So we have in 60.0.3107.5:

Left MouseDown: :hover:active is applied
MouseMove (inside element) :hover:active is STILL applied

touchstart: :hover:active is applied
touchmove (inside element) :hover:active is NOT applied

Right MouseDown: :hover:active is applied
MouseMove (inside element) :hover:active is NOT applied
I rethought a bit. Is this really a bug or intended behavior?

A touchmove can/does scroll the content so every interaction with this object could be interpreted as canceled. 
The interaction is now "scrolling the view" and not "activation of the div".

Comment 9 by r...@opera.com, May 31 2017

Status: Available (was: Assigned)
Components: -Blink>CSS Blink>Input
Labels: -Pri-1 Pri-2
Status: Untriaged (was: Available)
Hey input-dev team - can you provide some input (hah) here on what the correct behaviour here is?
Labels: Hotlist-Input-Dev
Status: Available (was: Untriaged)
That is correct. I don't recall the historical reason that we do that though. This issue 418188 was also related that we were doing some experiments with this behavior and correctly setting active and hover for touch pointers.
Project Member

Comment 12 by sheriffbot@chromium.org, Nov 26

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
Mergedinto: 418188
Status: Duplicate (was: Untriaged)

Sign in to add a comment