Tested this issue on Ubuntu 14.04 using chrome stable M55-55.0.2883.75 by following steps mentioned in the original comment. By double clicking "example.com" from URL  Observed only "example" got selected leaving ".Url" behind.

michael@ -Tested the same on chrome M53-53.0.2785.143 and observed similar behavior as mentioned above. Example.com is completely get's selected only after triple clicking. Not sure what's the actual issue you are observing here. Could you please confirm on which version did you observe that double click selects the entire Url from omnibox?
 

Hi,

I may have been confused about exactly what behavior has changed - however there does seem to be no way to select the whole URL by clicking since 55, I get either 'everything to the left of the mouse' selected or 'just one word' no matter how much I click.

I will install an older build tonight and make some animated GIFs showing the difference.

Thanks,
-Michael

Like brajkumar@ I tested on Ubuntu 14.04, this time using chrome stable M55-55.0.2883.87.  Triple-clicking selects the whole URL for me.

Can you provide more details about your setup?  What window manager are you using?  Also, does triple-clicking work in other apps?

(Also, I believe double-clicking has always only selected a single word in the URL bar on Linux, at least for me.)

Apologies for the confusion around double clicking - it seems I was unconsciously triple clicking and not realising it :(

It looks like there has been a regression in the triple click behaviour. I've replicated this on four different machines running the same software stack - latest Chromium 55 in Debian Jessie with i3 as a window manager. Triple clicking in other GTK and Qt programs selects a whole line, it just seems to be Chromium where this is broken.

To illustrate the problem I've made two GIF screen recordings showing me moving the mouse over the URL bar, triple clicking, unselecting the URL bar then repeating the action.

This first GIF shows Chromium 53.0.2785.143 (Developer Build) Built on 8.6, running on Debian 8.6 (64-bit), as it was in the Debian repos in October: https://drive.google.com/file/d/0ByYSbmc9YE-cR1VTTFVFV29keDg/view

Note how in this first video, the first click selects the whole URL, the second click selects a word and the third click selects the whole URL again.

This second GIF shows Chromium 55.0.2883.75 (Developer Build) Built on 8.6, running on Debian 8.6 (64-bit), from the current Debian repo: https://drive.google.com/open?id=0ByYSbmc9YE-cazdSNkZmVG1HTnM

Here the first click selects the whole URL bar, the second click selects a word, then the third click selects just from the left of the bar to the mouse pointer.

I'm finding it very difficult to un-train myself from triple clicking to select the whole URL!

I've attached the GIFs to this reply as well, in case the Google Drive links don't work.

Deleted: click_53_demo.gif 21.8 KB

	click_53_demo.gif 21.8 KB View Download

Deleted: click_55_demo.gif 19.9 KB

	click_55_demo.gif 19.9 KB View Download

Thanks for the videos (well, animated videos).

testing team - can you find a debian install and reproduce this issue?

reporter (michael@) - can you do me a favor and type "example.com" in the find-in-page box, focus on the web page, then focus back in the box and try the same experiment?  Does triple-clicking in the box work for you there?

adding UI->Input->Text label because this might be a textbox issue

CC derat@ because he tends to know a lot about Linux platform conventions and maybe he has something to say about this.

Triple clicking in the find-in-page box is A-OK :)

Unable to reproduce the issue on Linux Ubuntu-14.04 using chrome Stable version 55.0.2883.87 and reported version 55.0.2883.75 with the steps mentioned in comment#0.
Observed that by triple clicking the whole url got selected.
Adding the label TE-NeedsTriageFromMTV as we don"t have the debian machine.

Thanks..

CC'ng derat@ per c#7.

Re platform conventions, Linux Chrome selects all on single-click. I don't know of any other *nix apps that do that. It's a bit hard to reason about what the "correct" behavior is after that point.

Running gedit 3.10.4 (a somewhat arbitrary choice for a "standard" *nix app):
- single-clicking positions the caret
- double-clicking selects the word I clicked
- triple-clicking selects the entire line

Running stable Chrome 55.0.2883.87 with notion as my window manager[1], I see:
- single-clicking selects the entire URL
- double-clicking selects the word I clicked
- triple-clicking selects the entire URL

I see this Chrome behavior regardless of whether I start out with web content, the omnibox, or the find bar focused.

So Chrome doesn't seem that divergent from gedit, apart from the single-click behavior. Double- and triple-clicking seem to match.

I'm not aware of double-clicking ever having selected the entire URL (at least not since the move from GTK2 to Aura years ago). Can anyone else confirm that they see that behavior in M53?

Re triple-clicking selecting from the beginning of the URL to the pointer position rather than the entire URL, I'm able to repro that if I triple-click and drag (even just one pixel) before releasing after the third time the button goes down.

1. although I don't think that the WM is relevant here

Please put double clicking out of your mind - I was just confused about what I was actually doing (it is a rather ingrained habit to triple click the URL to select it, probably from a very long time ago). Triple click for "select whole line" is common in Linux terminal emulators, which is probably where it comes from for me.

The real bug here is that triple click in M53 selected the whole URL, whereas in M55 no amount of clicking after the first single click can select the whole URL (instead alternating between word selection and left-of-cursor).

I don't think I'm moving the mouse (even a single pixel) during the click process. I tried to script something with xdotool to verify this assumption but it doesn't work reliably.

Is there anything more useful I can do to debug on my end?

> Is there anything more useful I can do to debug on my end?
I think fundamentally we're waiting from someone on the MTV test team to track down a Debian machine to try to reproduce there.

I'm not able to repro this on Debian either.

I wonder if double-click delay (do we get that from GTK?) could be a factor. I don't have any ideas why we'd be selecting from the left end in the absence of a drag, though.

Removing Test confirmation labels as per c#14.

I just tried reproducing this on Ubuntu, which shouldn't deviate from Debian much. Can't reproduce this.

Original reporter, please re-open if you can still reproduce this on the latest Stable Chrome.

Hello!

I can confirm this bug is still present on Debian Jessie :( 

I've just installed a couple of Debian Stretch machines (one upgraded from Jessie and one fresh install) and the behaviour is back to normal on Stretch.

I'm mildly disappointed that this bug got WontFix'd even though I've clearly shown that it's a real problem in my GIF screen recordings.

In any case, the bug will be worked around as people upgrade to Stretch, so I guess that is an OK solution.

Thanks,
-Michael

Sorry about this; it's just that most of us don't have Debian machines, so anything specific to that is a pain to test and fix... :-(

Nevermind, just leave it as wontfix. I understand it's more work than makes sense at this point :)

It'd still be nice to know what is/was causing this. The Debian system where I failed to repro this was also running jessie, so I suspect that this is more likely to be due to something configuration-related than which version of a particular package is installed.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot