New issue
Advanced search Search tips

Issue 671003 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: Dec 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Omnibox has a glowing border

Reported by aarda.uu...@gmail.com, Dec 4 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36

Steps to reproduce the problem:
1. click on omnibox

What is the expected behavior?
Not having a border

What went wrong?
looks bad

Did this work before? Yes 54

Chrome version: 55.0.2883.75  Channel: stable
OS Version: 
Flash Version:
 
Screenshot from 2016-12-04 12-08-07.png
1.9 KB View Download

Comment 1 by ajha@chromium.org, Dec 5 2016

Components: -UI UI>Browser>Omnibox
Labels: M-55 Needs-Bisect
Owner: treib@chromium.org
I thought this was a dupe of  bug 668594 , but the reporter is on M55 stable?  I didn't think the change causing this was in the M55 branch.  (I wasn't even sure it was in the M56 branch.)

treib@, can you figure out what releases could have been affected by your change and make sure your fix got merged to the right branches?

Reporter, can you verify that you can reproduce this problem on Chrome 55 (as opposed to, say, reproducing it on a dev/beta build and then filing this bug with M55)?
I'm on Chromium 55 stable channel, and this is reproducible.
Labels: Needs-Feedback
Unable to reproduce the issue on Linux 14.04 chrome stable version 55.0.2883.75 and dev 56.0.2924.14 - No such focus in the omnibox

Could you please replicate the same  on a new profile and see if the issue still exists

Comment 5 by treib@chromium.org, Dec 6 2016

Owner: pkasting@chromium.org
My CL which broke this (https://codereview.chromium.org/2510373003) landed on Nov 23, more than one month after M55 branch point (in fact, even after M56 branch point), and it wasn't merged anywhere. If this is actually happening on M55, it must be a different problem.
I tried with a new profile and the problem doesn't persist, so i tried disabling flags, and it seems --top-chrome-md (#secondary-ui-md) causes this problem.
I'm not too worried about secondary-ui-md being broken on stable since that flag is experimental and off by default.  Is it still broken on Canary?  If not, I'll just close this as fixed.

(I can't reproduce this in my trunk build with --secondary-ui-md.)
Sorry, I can't test this with Canary, my subscription to my ISP ended yesterday and I have limited mobile data.
OK.  Is reproducing the problem on a clean profile possible by just adding the switch "--secondary-ui-md" on the command-line, or are any other steps needed?  (I prefer to specify command-line switches rather than flags since there's less ambiguity).

If we have clear steps to reproduce, then we can find someone test on Linux Canary/trunk.
Yes, adding "--secondary-ui-md" causes the problem with no additional steps.
Owner: est...@chromium.org
Cool.  I can't repro on Windows trunk.  Evan, can you try this on Linux trunk (see comment 10)?  If it doesn't repro there, we can just close.
Same issue happening on Windows 7, Chrome 55, with --secondary-ui-md.
qwe.png
38.3 KB View Download
Status: WontFix (was: Unconfirmed)
If it happens on Windows on Chrome 55, and not on my Windows trunk build, I'm going to claim we fixed this in the meantime somehow.
If your advice to users experiencing this to disable the "secondary ui md", either from about:flags or the command line?
To my knowledge we've never turned that flag on automatically, and it's known to be incomplete and not ready for public consumption, so the normal about:flags caveats apply.  Yeah, I'd just suggest turning the flag back off.

Sign in to add a comment