Regression:[MD] Unwanted focus highlight is seen wrench icon after closing wrench menu.
Reported by
rk...@etouch.net,
Mar 9 2016
|
|||||||
Issue descriptionChrome Version: 51.0.2672.0 Revision b4fd57023ade2863e463d3380456968dca6c8bcf-refs/heads/master@{#380022}(32/64 bit) OS: Windows(Win-7 Aero Enabled) Precondition: Enable 'Material design in the browser's top chrome' by selecting 'Material' option. URL: https://chrome.google.com/webstore/detail/save-to-pocket/niloccemoadcdkdjlinkgdfekeahmflj?hl=en What steps will reproduce the problem? (1) Launch chrome, navigate to above url and click on 'ADD TO CHROME' button. (2) Drag the extension icon on the wrench icon,hold it till highlight is seen on wrench icon. (3) Now release mouse outside the wrench menu(As shown in video) and observe. After step 3, Wrench menu gets closed but focus highlight is still seen on wrench icon. No such focus highlight seen on wrench icon after closing wrench menu. This is a regression issue,broken in 'M-50',below is a bisect info: Good Build: 50.0.2631.0 Bad Build: 50.0.2633.3 Narrow Bisect: https://chromium.googlesource.com/chromium/src/+log/9a1c85fb7079ce5ffc249c4a787058c81dccdd31..7f7eb25a8abd2d173c5ae1fe95d92e398cf70267?pretty=fuller&n=10 Suspecting: r371511 Note: Issue is not seen on Mac OS as, we can not drag extension in it.
,
Mar 9 2016
,
Mar 9 2016
I would not consider the bug as described in these repro steps to be a release blocker for M-50. Punting to M-51 for now, though if a simple low-risk fix can be landed and merged back into M-50 that would be a bonus. I will take a closer look tomorrow at the interaction between extension drag & drop and hover effects to see if any similar bugs can be triggered by use cases which are more common. If so, let's reevaluate.
,
Mar 11 2016
It turns out that this is easier to reproduce than I originally thought. Step (3) in the repro steps isn't necessary; the hover effect will remain even if the icon is dropped within the Chrome menu. Valery, what are your thoughts about priority here?
,
Mar 11 2016
I believe this will be fixed by this CL: https://codereview.chromium.org/1757993004/
,
Mar 12 2016
#5, thought so too. I would wait till you have a chance to try it with r380786.
,
Mar 15 2016
Ben, I see that https://codereview.chromium.org/1757993004/ landed and was merged back into M-50. Is this bug fixed now?
,
Mar 15 2016
I can't say for certain that that CL (i.e. https://codereview.chromium.org/1757993004/) was responsible for fixing this but it does appear to be fixed on tot. I'm going to leave this open for a bit and circle back on the M50 branch to confirm that this is also fixed there.
,
Mar 21 2016
I have verified this is fixed on 50.0.2661.32 Chrome OS beta-channel.
,
May 13 2016
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ranjitkan@chromium.org
, Mar 9 2016