New issue
Advanced search Search tips

Issue 827504 link

Starred by 2 users
Status: WontFix
Owner:
lgrey@chromium.org
Closed: Jun 2018
Cc:
nyerramilli@chromium.org
rbasuvula@chromium.org
fdoray@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Regression: Unwanted focus ring is seen on 'Back Navigation Icon' in omnibox.

Reported by aiman.an...@etouch.net, Mar 30 2018 
Chrome Version:67.0.3379.0 (Official Build)Revision 1a1fb435932e9d87bebcdb0a0b2c5e2f3de3a694-refs/heads/master@{#545319} (32/64 Bit).

OS: Mac(10.12.6, 10.13.1, 10.13.4)

Steps to reproduce:
1. Launch chrome and navigate chrome://flags and switch ‘Force UI Direction’ flag to ’Right-to-Left’.
2. Relaunch the browser and Observe.

Actual Result: Unwanted focus ring is seen on 'Back Navigation Icon' in omnibox.
Expected Result: Unwanted focus ring should not be seen on 'Back Navigation Icon' in omnibox.

This is a regression issue broken in ‘M-67’ and using per-revision bisect providing the bisect results,
Good Build:67.0.3381.0(Revision: 545919)
Bad Build:67.0.3382.0(Revision: 546346)

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

CHANGE-LOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/99346eaf452e11400555b3901e892c76f5534372..e616115a9b1dca27ffdf447c79b4413305c49bb4

Suspect: https://chromium.googlesource.com/chromium/src/+/e616115a9b1dca27ffdf447c79b4413305c49bb4

fdoray@Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Issue is not reproducible on Windows(7,8,8.1.10) and Linux(14.04 LTS) OS.

Thank You!
Actual Result.mov
1.4 MB View Download
Actual Result.mov
1.4 MB View Download

Comment 1 by jleedev@gmail.com, Apr 4 2018 

The flag is a red herring; this is just about restoring windows when chrome is restarted.

Note that 'Full Keyboard Access' (Control+F7, or System Preferences > Keyboard > Shortcuts) must be enabled, and the stable behavior in this case is that the omnibox should be focused.
Untitled.mov
2.9 MB View Download

Comment 2 by schenney@chromium.org, Apr 16 2018

Components: -Blink>Layout UI>Browser>Omnibox

Comment 3 by jleedev@gmail.com, Jun 4 2018 

This also happens when dragging a tab out of the window; the tab's close button or the new tab button will gain focus.

Comment 4 by mpear...@chromium.org, Jun 6 2018

Cc: fdoray@chromium.org
Owner: ----
Status: Untriaged (was: Assigned)
Marking as untriaged because fdoray@ is not respnosive.

Comment 5 by ellyjo...@chromium.org, Jun 7 2018

Labels: -Pri-1 -M-67 -Target-67 M-69 Proj-MacViews MacViews-Browser Target-69 Pri-3
Owner: lgrey@chromium.org
Status: Assigned (was: Untriaged)

Comment 6 by lgrey@google.com, Jun 7 2018

Status: WontFix (was: Assigned)
This is an unsupported use case (Either Chrome needs to be launched with -NSForceRightToLeftWritingDirection YES -AppleTextDirection YES, or system language should be changed to Arabic/Hebrew and the OS restarted or logged out of)

Comment 7 by jleedev@gmail.com, Jun 7 2018 

This isn't an RTL issue, and it happens with no flags set.

Comment 8 by lgrey@chromium.org, Jun 7 2018 

Thanks jleedev@gmail.com, I'm embarrassed to say I missed that above.

Since this doesn't doesn't reproduce on Canary, and probably doesn't meet the bar to merge to M67, I'm going to leave this closed.
►

Sign in to add a comment