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

Issue 698435 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit 22 days ago
Closed: Apr 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug


Participants' hotlists:
ViewsButtonRefactor


Sign in to add a comment

Tapping nav buttons leaves their tooltips open, and shows the highlight gray background

Project Member Reported by rpop@chromium.org, Mar 4 2017

Issue description

Chrome Version       : 56.0.2924.87
OS Version: 10.0

What steps will reproduce the problem?
1. Tap a nav button (back, fwd, home, reload)
2. Wait for navigation to happen

What is the expected result?
No tooltip

What happens instead of that?
Tooltip opens and stays open forever

See video:
https://docs.google.com/presentation/d/14jaX3op8_a87DXyFCZrSsU7mVA-666P707yvQbQ_84Y/edit#slide=id.g1ce581d6de_0_0

 

Comment 1 by rpop@chromium.org, Mar 4 2017

comment from tdanderson:
This and a lot of the other win-only bugs seem like the root cause could be that tapping the screen generates a different stream of ui events on Windows as compared to Chrome OS. Furthermore I believe that the Windows OS also fires WM_* messages at certain points which can lead to generation of further ui events. We should make it an eng priority to both understand how the two platforms differ in this regard.

Also at one point I did some work to differentiate between two different mouse cursor states: hidden (cursor is invisible but it is still present, giving persistent hover states) vs. disabled (cursor is not visible and has no effect). The persistent hover/tooltip here could also be due to a regression in that logic.
Labels: ViewsButtonRefactor
Labels: -ViewsButtonRefactor Hotlist-ViewsButtonRefactor
Note:  issue 699668  is evidence of my conjecture in #1 being at least partially to blame for the class of "hover states and tooltips remain when using touch" issues, rather than all the blame being placed on MD ripple states in buttons:  tapping on a tab will sometimes show its tooltip, but a tab is not part of the Button view hierarchy.

Comment 5 by girard@chromium.org, Apr 18 2017

Labels: Proj-TabletChrome-Phase1

Comment 6 by girard@chromium.org, Apr 19 2017

Owner: girard@chromium.org
Status: Started (was: Available)
Patch is at https://codereview.chromium.org/2829653002/
Project Member

Comment 7 by bugdroid1@chromium.org, Apr 20 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a19d2ff185b04105bf66c835f8bb84b8b5fb79b2

commit a19d2ff185b04105bf66c835f8bb84b8b5fb79b2
Author: girard <girard@chromium.org>
Date: Thu Apr 20 17:22:42 2017

Removed (spurious, touch-initiated) tooltips from nav buttons

Windows generates WM_MOUSEMOVE buttons at random points (to make sure
that apps know where the cursor is). In some cases the cursor location
was caused by a touch event - the mouse cursor jumps to the last touch
location.

This patch tracks the last touch location so that tooltips can ignore
those extraneous mousemove's.

BUG= 698435 

Review-Url: https://codereview.chromium.org/2829653002
Cr-Commit-Position: refs/heads/master@{#466046}

[modify] https://crrev.com/a19d2ff185b04105bf66c835f8bb84b8b5fb79b2/ui/views/corewm/tooltip_controller.cc
[modify] https://crrev.com/a19d2ff185b04105bf66c835f8bb84b8b5fb79b2/ui/views/corewm/tooltip_controller.h
[modify] https://crrev.com/a19d2ff185b04105bf66c835f8bb84b8b5fb79b2/ui/views/corewm/tooltip_controller_unittest.cc

Comment 8 by girard@chromium.org, Apr 24 2017

Status: Fixed (was: Started)

Sign in to add a comment