Issue metadata
Sign in to add a comment
|
Regression: Unnecessary focus highlight stays on arrow icon of download shelf after clicking on Wrench menu.
Reported by
jshan...@etouch.net,
Jun 23 2016
|
||||||||||||||||||||||
Issue descriptionChrome Version: 53.0.2776.0 07025e9df358bb0249550d6124b9817333421fc0-refs/heads/master@{#401299} (32/64 bit) OS: Windows (7,8,8.1,10) Steps: 1. Launch Chrome and downloads any web page using 'Ctrl+S' keys. 2. Click on arrow icon on download shelf, then click on Wrench menu and observe. Actual: Unnecessary focus highlight stays on arrow icon after clicking on Wrench menu. Expected: Focus highlight should not stay on arrow icon after clicking on Wrench menu. This is a regression issue broken in M-51, below is bisect info. Good build: 51.0.2671.0 Bad build: 51.0.2672.0 Narrow bisect: https://chromium.googlesource.com/chromium/src/+log/bb0409e5c66c91cca686b4c03d1ae7a3416573c1..7b1d1d89b247c0bd82d527c6ded5da4128883274?pretty=fuller&n=100 Suspecting: r379731 ? Please help to re-assign if your change is not the cause for this issue. Note: This issue is not seen on Mac and Linux OS.
,
Jun 23 2016
perhaps we need to port over the weird drop_down_pressed_ / OnMouseExited dance from DownloadItemView to DownloadItemViewMd?
,
Jul 3 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 3 2016
Note: Above issue is not reproducible on latest canary version: 55.0.2878.0, hence marking it as wontfix |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by est...@chromium.org
, Jun 23 2016Labels: -Pri-1 Pri-2
Owner: ----
Status: Available (was: Assigned)
I can't repro on linux, it's probably a windows-only thing. It seems possibly related to this code comment: // Similar hack as in MenuButton. // We're about to show the menu from a mouse press. By showing from the // mouse press event we block RootView in mouse dispatching. This also // appears to cause RootView to get a mouse pressed BEFORE the mouse // release is seen, which means RootView sends us another mouse press no // matter where the user pressed. To force RootView to recalculate the // mouse target during the mouse press we explicitly set the mouse handler // to NULL. static_cast<views::internal::RootView*>(GetWidget()->GetRootView()) ->SetMouseHandler(NULL); What does this look like without material design? The code is copied from there and the effect should be the same (the dropdown getting stuck in "depressed" state).