Verified in 51.0.2704.104.

I am de-assigning myself and going to try to find someone on iOS team who can fix it (since I am completely unfamiliar with iOS development).

The fix should be straightforward: the Omnibox's text paragraph direction needs to be set to LTR (not default) when it contains a URL. This is a bit tricky because we also allow search terms to be entered, which should be rendered with the default paragraph direction. On Android, we just made it LTR when not focused, default/auto when focused.

See the Android fix: https://codereview.chromium.org/1988553002.

+rbsoulhunter who previously reported this vulnerability and has been in contact with me about it.

Adding reward-topanel since this seems like a distinct issue.

If I set the text field alignment to NSTextAlignment I still see this bug:

https://screenshot.googleplex.com/Wa3vEP3WOM0

(lldb) expr [(UITextField*)0x7f893301be00 textAlignment]
(NSTextAlignment) $6 = NSTextAlignmentLeft

mgiuca@: Do you have an iOS sample that fixes this?

> If I set the text field alignment to NSTextAlignment I still see this bug:

This isn't an alignment issue, it's a paragraph direction issue. You have to set the paragraph direction to LTR.

Having said that, I tried doing a similar thing on Mac:
https://codereview.chromium.org/2126023003

and it had no effect. Possibly you'll run into the same problem on iOS.

> https://screenshot.googleplex.com/Wa3vEP3WOM0

Please attach screenshots to bugs, rather than linking to internal URLs.

> mgiuca@: Do you have an iOS sample that fixes this?

What do you mean an iOS sample? Do you mean a patch? No, I don't know anything about iOS (and I thought Rohit was looking at this).

Setting the paragraph direction doesn't work either.  

The only thing I could get to work was this: 
[mutableText insertAttributedString:
    [[NSAttributedString alloc] initWithString:@"\u200E"] atIndex:0];

But I don't know if this is a terrible idea or not:
https://chromereviews.googleplex.com/471117013/

I am not familiar with iOS, however after analyzing what you have done above, i think this might solve the issue. 

What you have done here is Forced LTR (left-to-right) by prepending the text with the "left-to-right mark" ((U+200E).

[mutableText insertAttributedString:
    [[NSAttributedString alloc] initWithString:@"\u200E"] atIndex:0];

I commented on the CL. It's *kinda* a bad idea (just because it physically modifies the text string that the user is also able to select, copy and modify). You can do it that way but care is required.

Any ideas why forcing paragraph direction doesn't work?

Looks like we were stomping on the paragraph direction override.  https://chromereviews.googleplex.com/471117013/ works

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/ios_internal.git/+/412ae8ee57897c11dab0a7b233884113cd5d70b0

commit 412ae8ee57897c11dab0a7b233884113cd5d70b0
Author: justincohen <justincohen@google.com>
Date: Wed Jul 20 23:19:44 2016

cmasso@ / srikanthg@ Can we do a quick look over RTL / omnibox functionality with this change?

I will take a look today and test around omnibox.
Tab tile is not updated correctly.
https://drive.google.com/a/google.com/file/d/0B-xmXLQhjeKua0NiVDFqS0hfQk0/view

Can you take a look if that needs to be fixed as well?

mgiuca@ do the same thing for tab title on iOS/Mac as well?

I wouldn't do this for tab titles, because those can be arbitrary text, and they're not intended to be any sort of security indicator.

#18 Good point but outside the scope of this bug (as Rohit says, those are not security indicators).

And we can't fix it in the rendering layer because as Rohit says, those can be arbitrary text. However, we can still address this at the place where the default title is created from a URL. I filed  Issue 630481 .

I've decided to request a merge on  Issue 624214  (Mac bug), and I think it's probably best to do the same here (if the code change is minimal). Good to have this bug fixed on Android, Mac and iOS in the same cycle.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/ios_internal.git/+/eb41acd6a0cba20c951443305f7e546ba9402cbc

commit eb41acd6a0cba20c951443305f7e546ba9402cbc
Author: justincohen <justincohen@google.com>
Date: Wed Jul 20 23:19:44 2016

 Issue 629668  has been merged into this issue.

 Issue 638465  has been merged into this issue.

Marking as reward-ineligible as this was considered part of the related issues when they were before the panel.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot