New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 739287 link

Starred by 1 user
Status: WontFix
Owner:
lgrey@chromium.org
Closed: Jul 2017
Cc:
nyerramilli@chromium.org
rbasuvula@chromium.org
█ msrchandra@chromium.org
█ ranjitkan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Regression: Separator line of omnibox overlaps with initial letter 'S' after hitting tab key

Reported by sans...@etouch.net, Jul 5 2017 
Chrome Version: 61.0.3149.0 (Official Build)4485eb651f6f09c3183285927fe82d17fcd7a13e-refs/heads/master@{#484159}-32/64 bit
OS: Mac (10.12.3,10.11.6)

Pre-condition: Select ‘Right-to-left’ direction for Force UI direction & ‘Enable RTL’ flag.

Steps:
1. Launch Chrome and navigate to https://www.facebook.com/
2. Open incognito window and type facebook.com such that 'Press tab to search facebook' is seen in omnibox
3. Press tab key and observe

Actual: Separator line of omnibox overlaps with initial letter of 'Search' i.e 'S' after hitting tab key

Expected: Separator line of omnibox should not overlap with initial letter of 'Search' i.e 'S' after hitting tab key

This is regression is broken in ‘M 61’ and below is manual bisect info:
Good build:61.0.3121.0
Bad build:61.0.3123.0

Note: Issue is not seen on Windows and Linux OS.
Actual_video.mov
5.5 MB Download

Comment 1 by sans...@etouch.net, Jul 5 2017

Labels: hasbisect
Owner: mbjorge@chromium.org
Status: Assigned (was: Unconfirmed)
Narrow bisect:  
https://chromium.googlesource.com/chromium/src/+log/f7d9e91e64165b26cbfd95d29c33d4d6f0b46126..cacba4879996384350b615f7578ff832230c0e2e?pretty=fuller&n=100

Suspecting: r477064 ?

Please help to re-assign if your change is not the cause for this issue

Comment 2 by mbjorge@google.com, Jul 6 2017 

Hmm, I don't see any other suspect CLs in that narrow bisect, but my CL is just a revert to the behaviour that had been around for a while (that CL that got reverted was only in the tree for ~2 weeks before it got reverted due to regressions).

Is this 100% reproducible on 61.0.3123 and 0% reproducuble in 61.0.3121? That particular CL was trying to fix a race condition in the RTL settings, so it's possible you're hitting a race condition? Or maybe some other subtle changes are affecting timing so that 3123 the race loses more often?

Comment 3 by mbjorge@chromium.org, Jul 6 2017

Owner: sans...@etouch.net

Comment 4 by shrike@chromium.org, Jul 6 2017

Labels: -Pri-1 -Type-Bug-Regression Pri-2 Type-Bug
Owner: lgrey@chromium.org
lgrey@ - please take a look.

Comment 5 by lgrey@chromium.org, Jul 10 2017

Status: WontFix (was: Assigned)
To get correct RTL behavior, in addition to MacRTL the app either needs to be 
launched with "-NSForceRightToLeftWritingDirection YES -AppleTextDirection YES" or the language must be Hebrew/Arabic (restart or relog required, just switching the language and restarting an application doesn't trigger something in the OS).

Without the above, the text system interprets "natural" text alignment as "left" and you see issues like this.
►

Sign in to add a comment