CC tedchoc@ in case he knows someone can add the probably trivial fix for this on Android

CC jdonnelly for iOS (find an owner or perhaps do it directly)

I was in that discussion and I actually disagreed/didn't think we should make the change without more investigation.

By focusing the beginning of the URL, we are making editing URLs quite a bit harder (because scrolling on android text is painful).  I suspect editing URLs is uncommon, but before we make it a lot harder, I think we should get metrics to show that it is done so infrequently that we are OK with this behavior.

What metrics would you believe?

Would the frequency of having a URL in the omnibox and then going via the omnibox (transition_type==typed) to another URL on the same hostname answer the question?  If this is low enough, say, <1% of all focuses in the omnibox when the omnibox is displaying a URL (i.e., not the NTP), then displaying the left side might make more sense.

That metric seems very reasonable to me.  In general, showing the left side probably makes for a prettier animation, but I can't imagine a case where it is more helpful.  So breaking an uncommon pattern to make for a more polished UI seems like a good tradeoff (whether that threshold is 1% or 10%).  <1% seems very, very easy to argue.

Yeah, I was imagining we could also measure the times a user goes to another URL via type without clearing the URL bar (or pasting now that I think about it). I'd want to avoid including users who clear the URL bar and type the same domain as they were on before since they won't be affected by this change.

I wonder if we can detect single character types into the omnibox.

> I'd want to avoid including users who clear the URL bar and
> type the same domain as they were on before since they won't be
> affected by this change.
I imagine this is small.

The nice thing about my proposal in comment #6 is that is could be done using existing logs.

The more sophisticated questions (does the omnibox get cleared at any point during the interaction, or did a paste-event that overwrote the omnibox) all require new logging.  How much do you care about these more nuanced questions?

Ah yes, let's start with the approach that you can use with existing logs since we can use that as an upper bound. Can you get per-user %'s as well?

Yes.

Adding keywords "edit URL", "edit URLs", "modify URL", "modify URLs" because I just spent five minutes trying to find this bug without much luck.

If I understood the bug correctly, we already do this on iOS (at least in UI Refresh). When the omnibox is focused, the pre-edit shows the beginning of the string, and exiting pre-edit doesn't move the selection, so you still see the beginning of the string. 

Therefore removing iOS.