It's present on Windows.  The workaround is, if you're going to be pasting on the keyboard anyway (with ctrl-v), use right-arrow/end to move the cursor to the end, rather than a mouse click.

Having double-click select a "word" is designed/desirable in certain ways, and I don't think we should remove it, although perhaps we should make it so the first click after "grant selection" is treated as click #1 no matter when it happens?  This will tick off people who intentionally double- or triple-click an unfocused box; I'm not certain it's the right thing.

What's definitely undesirable to me is the selection here of '/', instead of, say, "master/", as the "word" in question.   Bug 196326  covers our word-breaking proc to some degree.  I've morphed it to be about the non-URL case, and specifically, about Windows-native differences from our current behavior.

I think in the URL case, we should change our behavior across platforms to break based on URL subcomponents.  In the path, the subcomponents are /-separated.  In the host, .-separated.  In the query or ref, &-separated.  The scheme, username, password, and port are treated as single "words".

Ideally, IMO, we would select the word you clicked plus its trailing separator.  This is something mentioned on  bug 196326 .

I think that leaves us with two issues:

(1) Trying to avoid starting the double-click timer on a click-that-gives-omnibox-focus.  This would address the core issue here and probably be a usability win on net, but it may be tricky to implement and violate how some other people expect things to work.  I don't care enough about seeing this happen to try to resolve any contention and then do the implementation work, but I also weakly think it'd probably be good and thus don't want to just close.

(2) Fixing the word-breaking proc so double-clicking part of a URL selects something that will likely still leave the URL valid if you remove/replace it.  I feel pretty sure we should do this.

I'm sort of inclined to morph this to be about (2) since I said on other bugs I'd do that and since I feel confident of that much, but it's kind of a bug morph, so maybe instead I should file that as a new bug?  Dan, what do you think of all this?

Thanks. Just to be pedantic, I didn't click any words -- I clicked way off in the empty space to the right of the current text. (I think that selecting the final "word" here is still intentional behavior, though. Blink textareas appear to behave similarly.)

I suspect I'm going off into the weeds here, but what if the omnibox didn't select the final word when it sees a double-click in the empty area to the right? When I want to replace a word in the omnibox, I double-click it directly.

Hmm.  Clearly we can't disable single-clicking there to place the cursor at the end, or dragging to start a selection.  You'd disable double-clicking (making double-clicks there just act like repeated single clicks?).  Would you also disable triple-clicking there?

As you note, selecting the final word here is intentional; we can change this behavior, but much like in comment 2 item (1), I'm uncertain about this.

Re #2:

(1) I think that have double-click-on-word-in-unfocused-omnibox select the word is useful behavior for some cases like wanting to correct a mistyped domain name, and I don't think we should disable it.

(2) I'm not sure about this. So if I accidentally typed "www.gogle.com" and then double-clicked "gogle", we'd highlight "gogle." rather than "gogle"? I don't think it would bother me if we did that, but I don't have strong opinions either way. I agree that it feels separate from this and that it'd be best to track it in a new bug.

I think what I'm hoping for at this point is special omnibox behavior where double-clicking in the empty space to the right of the URL doesn't highlight the "last word" (however that's defined), perhaps only when the omnibox is initially unfocused.

Good point re triple-clicking.

For the initially-unfocused case, I think triple-clicking is meaningless on Windows and Chrome OS (it selects all just like a single-click, right?), but it's how you copy the current URL to PRIMARY on Linux, and I wouldn't want to break that.

For the already-focused case, triple-clicking is the easiest way to select all using the mouse, right? That's also something I wouldn't want to break.

I'm having a hard time thinking of any good ways to reconcile this, so maybe WontFix is the way to go.

Re (2):

Windows does a really weird thing where it selects the trailing separator, but it won't always replace it.  For example:

abc def ghi

If you double-click "def" in Wordpad, the space afterwards is selected.  If you hit backspace, all four characters are deleted.  But if you type 'a' instead of hitting backspace, you replace only "def".  It's kinda bizarre and non-intuitive, but it works somewhat well in practice.

So one option would be doing that.

Another would be to do the simpler thing where we just really select the trailing separator and if you start typing we blow it away.

Re comment 3/5:

I'm still curious what you'd do with triple-clicking, and I'm still concerned about whether introducing this inconsistency with e.g. Blink textareas is the right thing to do.

Oops, we talked past each other.

I think your cases are good reasons not to break triple-clicking here.  If we allow single- and triple-clicks here to work I have a hard time saying double-clicks shouldn't.  But I do see the use case you're describing so I'm waffling.

Re "abc def ghi", didn't WebKit also have that behavior at one point? It looks like Blink doesn't now, at least on Linux and Chrome OS, but I could believe that this is a settable option that we've turned off on non-Windows platforms.

Okay, I'll hopefully get around to taking a look at what it'd take to make double-click-on-empty-space-when-unfocused just move the caret to the end of the text without highlighting anything, and then see what it feels like. Thanks for all the input on this.

Given the time since the last comment, this bug is certainly not P-2.