I'm not seeing this. The Omnibox has always selected-all when you clicked it. In 69, when I click again, yes, the URL gets a scheme prepended, but the Omnibox preserves the click location. Are you not seeing the location preserved? Or is it something else?

Mac triage: assigning to jyasskin@ for followup per #1.

Since the whole URL *moves*, preserving the location of the click can only be a partial solution. When I do a click and drag, since the URL has shifted to the right, the drag location is farther left than I actually clicked.

Deleted: Untitled.mov 1.0 MB

	Untitled.mov 1.0 MB View Download

Another example, interacting with view-source. The second click lands in a seemingly random position (between the slashes, between the second pair of w's).

Deleted: Untitled.mov 2.2 MB

	Untitled.mov 2.2 MB View Download

[omnibox triage]

jleedev@,
we've made some improvements in this behavior recently.  Can you please let me know what Chrome version those videos are coming from.

Assigning to tommycli@, who's dealt with this complexity before.

I don't remember what version that was yesterday, but the behavior is the same in Canary 70.0.3510.0 today.

To elaborate, here's what I'm seeing:

Old behavior: URL stays put until I edit some text. This is predictable for all permutations of clicking, double clicking, dragging, arrow keys, etc.

New behavior: URL jumps if it is already focused and I click, select text, press an arrow key, double click, start dragging, etc.

I do see that when this happens, the *first* click location is translated to the same relative position after the text has moved, but subsequent clicks are not.

So here's what's happening, step by step:

1. Visit https://www.google.com.
   - Omnibox shows [google.com].
2. Click once anywhere in the omnibox.
   - Entire text is selected, view is unchanged
3. Double click on the word [google].
   - Text changes to [https://www.google.com].
   - [https] is selected.

In the video in c#3, it looks like you are double-click-dragging.

In other words, it looks like you are doing:

Mousedown
Mouseup
Mousedown
Drag

Is that accurate?

Yes (it selects words).

Okay great. So it sounds like normal dragging is working alright - but double-click word-selection is unintuitive.

Is that correct?

Yes, normal dragging is working.

Un-elision during double-click-and-drag feels weird, and I would hope that it's a straightforward fix to keep the elided state during this gesture.

If the URL is to jump around, doing so when the mouse button is released ought to be the least surprising, if the user is not about to immediately press the button again.

Awesome - thanks for the feedback. I will investigate if there's a way to accomplish this.

This behavior is very annoying when attempting to select and edit or copy a portion of a URL. The recent changes to elide "https://www" from the prefix of a URL are especially annoying, because the URL jumps around significantly underneath the mouse when doing double-click selection.

Could this new UX please be rethought? This is being noticed by other colleagues, too:

https://twitter.com/FlohOfWoe/status/1039534856001208320

Upgrading to P2 regression.

 Issue 896120  has been merged into this issue.