Issue metadata
Sign in to add a comment
|
Regression: Focus ring is stuck on previous option even after clicking on any other option in origin info bubble
Reported by
jshan...@etouch.net,
Nov 30 2016
|
||||||||||||||||||||||
Issue descriptionChrome Version: 57.0.2936.0 (Official Build) 325a49517707810d1abdfb0040e19b7abb5addbe-refs/heads/master@{#434845}-32/64 bit OS: Windows (7,8,8.1,10),Linux(Ubuntu 14.04 LTS) Precondition: Enabled Material Design in the rest of the browser's native UI flag from chrome://flags. Steps: 1. Launch Chrome and navigate to any web page like https://www.google.com/intl/en/chrome/browser/welcome.html 2. Click on lock icon of omnibox and press tab key till focus ring is seen on first permission-'Location' of origin info bubble 3. Now click on any other permission drop down like Camera, Microphone, etc and observe. Actual: Focus ring is stuck on previous option even after clicking on any other permission Expected: Focus ring should not get stuck on previous option after clicking on any other permission This is a regression issue broken in M-55, will soon update the bisect info: Good Build: 55.0.2846.0 Bad Build: 55.0.2847.0 Note: Above issue is not seen on Mac OS.
,
Nov 30 2016
Adding RB Label as this is a recent Regression. Thank You.
,
Nov 30 2016
Adding M-55 stability owners.
,
Nov 30 2016
We're cutting M55 Stable RC today for release this week. Please let us know ASAP if this is indeed Stable blocker. Thank you.
,
Nov 30 2016
Please don't mark the bugs which are reported using Material design flags as blockers, Since the feature is behind the flag. estade@ please correct me if I am wrong, I am removing the stable blocker label.
,
Nov 30 2016
comment 5 is correct
,
Dec 5 2016
Gentle ping!! Still we are able to reproduce the issue on Windows 7-with Chrome Latest canary #57.0.2939.0. Shrike@ Could you please look into this issue. Thank you.
,
Jan 16 2017
Gentle ping!! Still we are able to reproduce the issue on Windows 10 with Chrome Latest canary #57.0.2983.0. Shrike@ Could you please look into this issue. Thank you.
,
Jan 16 2017
-> pkasting@ for assignment.
,
Feb 14 2017
Elly has been working on this dialog.
,
Feb 14 2017
Hm, the difference is because in non-Harmony mode on Linux/Win, this dialog uses MenuButtons instead of Comboboxes. MenuButtons support taking focus on press, and this dialog enables that behavior, but Comboboxes do not. I'm not sure if taking focus on mouse press is actually the right behavior, though... certainly Mac apps do not behave that way.
,
Mar 8 2017
,
Mar 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a0edc14c6fae6412feb1fabdef2d7e3372cd86dd commit a0edc14c6fae6412feb1fabdef2d7e3372cd86dd Author: ellyjones <ellyjones@chromium.org> Date: Fri Mar 10 17:20:59 2017 views: make comboboxes request focus when clicked They should behave this way on non-Mac, even in Harmony mode. BUG= 669778 Review-Url: https://codereview.chromium.org/2739893003 Cr-Commit-Position: refs/heads/master@{#456086} [modify] https://crrev.com/a0edc14c6fae6412feb1fabdef2d7e3372cd86dd/ui/views/controls/combobox/combobox.cc
,
Mar 10 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by msrchandra@chromium.org
, Nov 30 2016Owner: est...@chromium.org
Status: Assigned (was: Unconfirmed)