Android UrlBar: Fix regression introduced by previous scrolling fix.

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 f0c4e28f50f1ebc13f130246176aec3253084c3e..9d870f104648ac0d4318b68d78dfd513c604b643 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
@@ -634,7 +634,7 @@ public class UrlBar extends AutocompleteEditText {
         if (urlComponents.first.length() > 1) {
             bringPointIntoView(1);
         }
-        bringPointIntoView(urlComponents.first.length());
+        setSelection(urlComponents.first.length());

[Ted C, 2017/05/25 23:41:17]

would setSelection(0, urlComponents.first.length()) work or does that show the
selection bounding box?

I'm a bit worried that bringPointIntoView has different timing semantics than
setSelection, so this might set the selection but doing the small wiggle of the
omnibox might force it to be scrolled all the way to the front?

[tommycli, 2017/05/25 23:49:42]

Hey, from what I was able to tell, setSelection(0, x) never had any different
from setSelection(x). I would be happy to change it to setSelection(0, x), but
it never had any benefits from what I could tell.

Hmm... I'm not sure about the wiggle comment... not sure how to interpret that.

But my reading of setSelection is that it enables the predraw listener, and then
calls bringPointIntoView on the next call to onPreDraw. So... it can only occur
after bringPointIntoView... it can't jump ahead of the previous
bringPointIntoView.

 
         return true;
     }