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

Issue 699944 link

Starred by 5 users

Issue metadata

Status: WontFix
Owner:
Last visit 22 days ago
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression


Participants' hotlists:
ViewsButtonRefactor


Sign in to add a comment

Regression : Unnecessary gray focus stay on 'up arrow' button in download shelf.

Reported by yfulgaon...@etouch.net, Mar 9 2017

Issue description

Chrome Version : 57.0.2987.98 (Official Build) f87f641e0af5bfed98578e340f1d5ca79651bf82-refs/branch-heads/2987@{#802} 32/64 bit
OS : Windows (7,8,10)

What steps will reproduce the problem?
1. Launch chrome, open NTP, press 'Ctrl' + 'S' and save the current page.
2. On download shelf, click on up arrow button twice.
3. Move the mouse and click anywhere on the page (NTP), observe the gray focus on 'up arrow' button in download shelf.

Actual : Unnecessary gray focus is seen on up arrow button in download shelf.
Expected : Focus should not stay on up arrow button in download shelf once user hit 'Esc' key or click somewhere on the page.

This is a regression issue broken in ‘M-56’, below is the Manual Regression range and will soon update other info.
Good build : 56.0.2913.0
Bad build : 56.0.2914.0

Note : This is Windows(7,8,10) OS specific issue and it is working fine on Mac (10.11.6, 10.12.1, 10.12) & Linux (14.04 LTS) OS.
 
Actual_Result.mp4
1.0 MB View Download
Expected_Result.mp4
903 KB View Download
Cc: rbasuvula@chromium.org
Labels: hasbisect-per-revision
Owner: bruthig@chromium.org
Status: Assigned (was: Unconfirmed)
Using the per-revision bisect providing the bisect results,
Good build:56.0.2913.0 (Revision: 430459).
Bad build:56.0.2914.0  (Revision: 430837).

You are probably looking for a change made after 430489 (known good), but no later than 430490 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/a4682914fc8311ff96c6b4f2a4ee890f36c56e97..ca8b19cd01cfb691bfa31e4605f4204dd8da8aab

From the CL above, assigning the issue to the concern owner

@bruthig  : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url: https://codereview.chromium.org/2447523002
Note :Windows specific issue and Able to reproduce in latest Canary #58.0.3035.0
Labels: Hotlist-ViewsButtonRefactor
I'm wondering if the fix for  Issue 719399  also addresses this.  Can someone easily check on Windows if this is fixed since 60.0.3107.0?
Cc: bruthig@chromium.org pkasting@chromium.org
 Issue 668942  has been merged into this issue.
Owner: girard@chromium.org
girard@, would you mind taking a look at this one?

I think we need to implement a similar solution to the one found here: https://codereview.chromium.org/2880623002/.

More concretely:

- SetHovered(false) in DownloadItemView::ShowContextMenuImpl()
- conditionally SetHovered(true) based on CustomButton::ShouldEnterHoveredState() after the menu is dismissed, perhaps in DownloadItemView::ReleaseDropdown().

This may require some visibility changes so that the DownloadItemView can access dropdown_button_->ShouldEnterHoveredState() and it's ink drop, or perhaps a dropdown_button_ can be a more specific subclass of ImageButton.
 Issue 727628  has been merged into this issue.

Comment 7 by girard@chromium.org, May 31 2017

Labels: Proj-TabletChrome Proj-TabletChrome-Phase1
Cc: est...@chromium.org
 Issue 729498  has been merged into this issue.
Status: WontFix (was: Assigned)
Testing in 61.0.3137.0 under win10, this no longer reproduces.

Tagging as "wontfix" - please reopen if you can reproduce.

Sign in to add a comment