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 28 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Android , Windows , Chrome
Pri: 3
Type: Bug

Sign in to add a comment

:hover being sticky on tap makes good multi-input design hard

Reported by, May 5 2014

Issue description

Chrome for Android (and Chrome OS) applies :hover styles when a user touches an element. This behavior is for compatibility with desktop sites which have drop down menus and require hover styles to work. By applying this state after a touch, a developer has to expect any hover styles to stick on mobile. This means adding styles for a pointer hover indicating a button is interactive, can't be separated from an :active state when touched on a mobile device.

The proposal is to never set :hover on touch on sites that set a mobile viewport set (i.e. sites with viewport <= the device width).


We refined this further on the thread.  I believe we _do_ want to set :hover while the element is being touched, we just want to clear it on tap (and tap cancel) instead of letting it be sticky today.

We should probably still allow longpress to trigger sticky hover.

See IE behavior here:

Ideally we'd eventually make chrome behave the same on all sites, but since this is probably too much of a breaking change for legacy desktop sites we'll start by doing this only for sites with a mobile viewport (i.e. exactly the same sites for which we disable the touch ACK timeout).

Comment 2 Deleted

What's wrong with giving :active a higher specifity in your CSS?
Or using media queries for your :hovers?
Then legacy hover menus would not break with so called "mobile viewport". What is a "mobile viewport"? I cannot find a definition in any spec. Is a mobile viewport any viewport on a mobile? Or touch device? Or is a viewport with certain configuration, e.g. width=device-width, considered mobile disregarding any actual form factor?
Why do you propose it here and not to Touch Events? And why is it more relevant what IE Pointer Events do than what other Touch Events implementations do?

"What's wrong with giving :active a higher specifity in your CSS?"

This bug is referring to the issue of hover sticking at the end of touch. I think rbyer's point of having hover apply during the touch is a valid point and should be applied, in which case active would apply over hover.

"Or using media queries for your :hovers?"

You can add bluetooth mouse and keyboards to a mobile device, so you would want hover support for these scenarios.

From the discussions I've had a "mobile viewport" is a site which has a viewport set to a size which is less than or equal to the device-width. We are taking the meta viewport as a signal that the developer cares about mobile and touch devices. It's not perfect but seems to be a generally good rule of thumb.

I don't think this is actually part of the Touch Events spec, rbyers do you agree with that (You're better placed to answer this than me)?

And it's not important what one browser does over the other. This behavior was included to support "legacy hover menus" with no way of getting out of the compatibility mode that it introduces. The only reason I originally mentioned IE is to validate that it's not an insane idea to remove the sticky nature of :hover.
> I don't think this is actually part of the Touch Events spec, 
> rbyers do you agree with that (You're better placed to answer this than me)?

Right, interaction with hover etc. was left out of the touch events spec because implementations already differed at that point.  The PointerEvents spec does a much better job of defining the behavior for devices that don't support hover (eg. but still doesn't explicitly mandate a specific behavior for :hover (although it's implied by the expectation/note that it'll match the enter/leave events)

Comment 6 by, Aug 19 2014

Summary: Don't make :hover sticky on tap on sites that set a mobile viewport set (was: Don't set :hover on touch on sites that set a mobile viewport set)
Note that :hover should still be sticky on long press.  Basically this will match IE10's behavior.

Comment 7 by, Aug 19 2014

Blockedon: chromium:401159
See for more discussion of the problem here.

See  issue 401159  for a concrete example of this with our built-in video player.

Comment 8 by, Aug 19 2014

Blocking: chromium:404128

Comment 9 by, Aug 19 2014

Note that if we're changing :hover behavior, we should probably change mouseover/mouseout/mouseenter/mouseleave behavior to match.
Some findings (on Android) & questions w.r.t implementation, after investigating Blink's EventHandler & Document implementation

For single Tap case, event sequence:
GestureShowPress => sets :active & :hover states
GestureTap => Clears active state, But not clearing hover state (:hover is sticky)
==> I have tried a fix that clears hover state after GestureTap.

For LongTap case:
GestureShowPress => sets :active & :hover states
GestureTapDownCancel ==> Clears active state, But not hover state (after Touch moves a distance OR Touch ACTION_UP)

==> can be fixed by sending HitTestRequestType as "NOT readonly" for GestureLongTap.

Question here:
- Behavior when "touch moves after long touch down"? should it clear :hover style?
  For eg., in current implementation, when a Node has both :active & :hover styles, Then while keeping touch down, :active style is visible and when touch moves, :active style is cleared. Thus, :hover style is visible (after receiving GestureTapDownCancel). according to comment #1 "we just want to clear it on tap (and tap cancel)", my patch proposal clears the hover in this case.

I think it would be easy to discuss this with the patch. May I submit a initial patch for discussion?
Ugg, yeah, I've noticed lingering style effects after a tap is activated/cancelled, so it would be great to get that cleaned up.
Note that the "lingering style effects after a tap is activated/cancelled" was an intentional design choice in safari to help make mouse-oriented hover menus usable with touch.  We will break some scenarios by changing this. That said, I think we should - the current behavior is developer hostile, makes it very hard to use :hover sanely in a responsive site design for touch and mouse (i.e. it favors compat with legacy code over having a rational platform).

So yes, I'd be interested in seeing a patch that changes this in a carefully controlled way - eg. by leaving the behavior as-is for pages without a mobile viewport (eg. see WebViewImpl::shouldDisableDesktopWorkarounds()).  But it's going to be non-trivial to get this right, and we might still find we have to revert for compat sake.

> "Behavior when "touch moves after long touch down"? should it clear :hover style?"

Personally I think we should retain :hover style here.  Play with this on IE (in general, matching IE's behavior exactly seems like potentially a good goal - they've put a lot of thought into this stuff).  I believe they've designed longpress as an explicit hover workaround gesture.  On Safari it's sometimes necessary to longpress then move in order to trigger a hover menu (eg. without sending click).  I'd prefer not to loose this (hard-to-discover) escape hatch...

Comment 13 Deleted

Patch is here:
Please provide your comments.
Status: Started
Assigning this to myself to track since since doesn't yet have chromium bug access.
See blink-dev PSA thread here for further discussion:!topic/blink-dev/DllLcNXHfHw
Blocking: 536263

Comment 19 by, Jun 17 2016

Related WebKit bug:
Owner: ----
Status: Available (was: Started)
Labels: -Pri-2 Pri-3
Rick, from the blink-dev PSA(!topic/blink-dev/DllLcNXHfHw) it seems like we no longer want to tie this to viewport being set, is that right? Is there anything more we want to do in this bug?
Labels: Hotlist-Interop
Summary: :hover being sticky on tap makes good multi-input design hard (was: Don't make :hover sticky on tap on sites that set a mobile viewport set)
Yeah the right fix is not at all clear.  It does seem like there's a bug to be solved here though.  Updated the summary to describe the problem, instead of a possible solution.

I'd argue the next step is to file a GitHub issue on some spec somewhere to discuss the problem with the other browser vendors.  Maybe one of them has a behavior that has worked out well for them which we could just copy?  Eg. IMHO Edge has thought this through more than we have.

Not sure if that's HTML or selectors-4:

Since Microsoft is interested, I'd suggest the latter in order to get them engaged.
Did a quick comparison here:
Edge: :hover goes away with touch release but :active stays on for a fraction of a second.
FF: :hover is sticky like in chromium, but :active doesn't appear without a quick short drag.

Part of our plan to overhaul mouse hover problem (Issue 488886) is that we would infer hover state from mouse boundary events instead of tracking a separate state.  Note that we would need consistent mouseout/leave events for touches if we ever decide to switch chromium behavior to match Edge for this bug here.
Blockedon: 369044
Tying to the viewport was tried (and reverted for web compat issues) in issue 369044.

In general our emerging story for fixing "footguns required for web compat" is feature policy:, with the hope that someday we'll have a new standard policy set that most new sites use.

So perhaps we should consider a "hover on touch" feature policy that can be disabled?  +iclelland
That's an interesting idea -- for feature policy, I would want to make sure that two things are true --

1. When disabled anywhere in the frame tree, hover-on-touch would be disabled for that frame and all of its descendants, with no way to re-enable it. Does this make sense? (I think so)

2. Would sites want to disable this feature unconditionally, for all visitors?
 There's not really a way to disable the feature at the top-level programmatically -- since there's no containing frame which can set policy via an attribute, you'd need to set it through an HTTP header. This means that if you want to disable for some clients and not others, you'd only have the HTTP request to use to make that decision.

Also, would the initial state of hover-on-touch always be 'enabled', or would it be set heuristically by the browser? (Always-enabled-by-default is definitely better for predictability, so I'd encourage that, as long as it doesn't cause bigger problems on the open web)

Sign in to add a comment