Android URL formatting: Disable RTL URLs for Android 4.2 and below.

chrome/android/java/src/org/chromium/chrome/browser/omnibox/UrlBar.java

Index: chrome/android/java/src/org/chromium/chrome/browser/omnibox/UrlBar.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/omnibox/UrlBar.java b/chrome/android/java/src/org/chromium/chrome/browser/omnibox/UrlBar.java
index 9dc8a9860b4073bb498982825d4de174ba3cdef4..bdfcf546429a20181174647f210263037ddc5ce7 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/omnibox/UrlBar.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/omnibox/UrlBar.java
@@ -12,6 +12,7 @@ import android.graphics.Canvas;
 import android.graphics.Paint;
 import android.graphics.Rect;
 import android.net.Uri;
+import android.os.Build;
 import android.os.StrictMode;
 import android.os.SystemClock;
 import android.text.Editable;
@@ -758,6 +759,13 @@ public class UrlBar extends VerticallyFixedEditText {
      */
     public boolean setUrl(String url, String formattedUrl) {
         if (!TextUtils.isEmpty(formattedUrl)) {
+            // Because Android versions 4.2 and before lack proper RTL support,
+            // wrap the formatted URL with LTR control characters.
+            // This is quite hacky, but fixes a security bug. crbug.com/709417
+            if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.JELLY_BEAN_MR1) {
+                formattedUrl = '\u200E' + formattedUrl;

[tommycli, 2017/04/27 01:36:33]

This I have confirmed does not negatively affect the copy and paste. This is
because mOriginalUrlLocation is used for copy and paste, not the formatted URL.

Also... it prevents android specific code from creeping into the platform
neutral C++.

One negative... there's no Android constants for '\u200E', so I just had to jam
in in there... Overall I think this CL is better though.

It also fixes alignment. I added a screenshot to the bug.

Please take a look... i'm not 100% sure that the LRM character is the right one
to use, but https://www.ietf.org/rfc/rfc3987.txt hints that it is...

[Matt Giuca, 2017/04/27 03:33:07]

Yeah this looks like exactly the right spot.
Yeah. I would prefer a constant declaration even if it's just at the top of this
class, so it's clear that '\u200e' is the LRM.
Good!
That document says it should be "the same way as they would be if they were in a
left-to-right embedding", so explicitly that's U+202A at the start and U+202C at
the end. It later says that a LRM "may be sufficient".

I think these are equivalent as long as it's applied to the whole paragraph.
(i.e., LRE..PDF around an entire para is equivalent to LRM at the start of a
para). The only difference would be if the string was concatenated to other
strings; then it would be important to use LRE..PDF. I think it's fine either
way.

I think this is sufficiently clean that we make it the universal rule on Android
(remove the setParagraphDirection API call and always use this). This can be
done in a follow-up CL.

[Ted C, 2017/04/27 16:26:50]

Agreed...I didn't even know what this was before reading this patch.

I'd be tempted to even include the ietf link you did (or mention the RFC by
number) as I don't think many future code readers would understand the
importance of the 

[tommycli, 2017/04/27 17:23:14]

Done. Great I made a constant at the top of the file, as well as included the
ietf link in the comment.

This is fairly clean -- but I'm not sure it's a complete replacement for higher
API levels. The higher API levels do tricky stuff where they restore the text
input direction to RTL when the input is focused for editing.

This patch doesn't support that, and leaves the text LTR even during editing.

+            }
+
             try {
                 URL javaUrl = new URL(url);
                 mFormattedUrlLocation =