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

Issue 616702 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Android: Omnibox text alignment is based on paragraph direction; should be based on UI language direction

Project Member Reported by mgiuca@chromium.org, Jun 2 2016

Issue description

Version: 53
OS: Android

What steps will reproduce the problem?
(1) Set system language to Hebrew.
(2) Navigate to: http://xn--cebn.com/
(3) Navigate to: https://xn--cebn.com/
(4) Navigate to: http://example.com/

What is the expected output?
URLs should always be aligned to the right when system language is Hebrew.

What do you see instead?
(2) is aligned right; (3) and (4) are aligned left.

The alignment is based on the paragraph's first strong character. Problems with this:
- This isn't really very logical (there isn't a strong correlation with first strong character and whether the URL is read as LTR or RTL).
- It's not what we do on Desktop (we always align with the system language).
- It means you get arbitrary things like the entire alignment changes depending on whether it's http (which is implicit) or https (which is explicit).
- There's a bunch of code to re-align the suggestions boxes to match which could be deleted if we just made this sensible.

Easy fix; I'm happy to do it as part of  Issue 609680 .
 

Comment 1 by bauerb@chromium.org, Jul 27 2016

 Issue 609680  is marked as fixed :)

Comment 2 by mgiuca@chromium.org, Jul 27 2016

Yes, but I ended up not doing it as part of that (that ended up being complicated and I didn't want to conflate this). I'll have another go at this because I still think it's correct to fix it.

Comment 3 by js...@chromium.org, Sep 9 2016

Cc: js...@chromium.org
mgiuca@, in  bug 609680  comment 25, you wrote:

> Ideally I think Android should follow desktop and set the alignment based on the 
> language, not the text, but that's outside the scope of this bug.

I agree with you on the alignment of URLs, but users are likely to have different expectation for non-URLs given what other apps and google.com do: 

The search box at www.google.com (and Android GSA. I guess GSA on iOS does that, too) changes the alignment dynamically based on what's typed (regardless of UI languages). OTOH, desktop Chrome does not do that in the omnibox while Android does. 

If Android Chrome changes its behavior to match the current Chrome-desktop behavior, it'll be an improvement for URL but kinda regression for non-URL. 





Comment 4 by rolfe@chromium.org, Mar 29 2017

Cc: -rolfe@chromium.org maxwalker@chromium.org
Removing myself and adding maxwalker as the primary design contact for omnibox
Labels: Needs-Feedback
mguica@, has this been fixed with your recent work on RTL URLs?  (I admit I haven't been following it closely so I don't know what the fixes you made encompass.  And I'm having trouble navigating my Android device using a Hebrew interface...)

Comment 6 by mgiuca@chromium.org, Jun 16 2017

Cc: mgiuca@chromium.org
Labels: -Pri-2 Pri-3
Owner: jdonnelly@chromium.org
No, it's still not fixed.

Assigning to jdonnelly (I've been handing off Omnibox responsibilities to the Omnibox team).

Downgrading to P3. Note this is not security and it a minor UI polish (though it is a bit confusing).
Labels: -Needs-Feedback Hotlist-Polish

Sign in to add a comment