Important clarification: "Did not occur in version 63 or so" == "CTRL+Backspace respected decimal points regardless of what surrounded them until version 63 or so"

Thanks for filing the issue!

Checked the issue on latest Chrome stable version 65.0.3325.181 and on M63(63.0.3205.0) using Ubuntu 14.04 with the below mentioned steps.
Note: Similar behaviour is seen on reported version 65.0.3325.162.
1. Launched Chrome
2. Typed 11.aa aa.111 11.11 aa.aa in omni box.
3. Hit Ctrl+Backspace.
We observed similar behaviour on both the mentioned M65 and M63 versions. Attaching the screen cast of the same.

@Reporter: Could you please have a look at the screen cast and let us know if we have missed anything in the process. It would highly helpful if clarified on whether the issue is specific with Arch Linux. Any further inputs from your end may help us.

Deleted: 827794.mp4 606 KB

	827794.mp4 606 KB View Download

NOTE: Additional information has been found that may justify a subject/title change; see middle section

--

Thanks very much for making the screencast. Pictures can convey worth many thousands of words sometimes! It made figuring this out so much easier.

As you noted, the behavior you see is indeed _similar_ to what I described, but not quite the same. It was interesting tracking the differences down... the attached video shows the result of testing 11 different Chrom{e,ium} versions from various sources (mostly Google), and demonstrating the different behavior from each. (The video is quite repetitive so the pace is fast but just slow enough to easily pause where needed.)

At this point, this oddness appears to be due to an as-yet unidentified Arch Linux-specific build-time configuration difference. I've opened an Arch bug to ask the maintainer(s) for further assistance: https://bugs.archlinux.org/task/58161

* There is one piece of information that may be helpful to know. *
I can't speak for the package maintainers, who definitely know more about Chromium [packaging-related internals] than I do, but it _may_ be useful for a Chromium engineer to point in the general direction of where the code that influences CTRL+Backspace might be, particularly any potentially-related external libraries that get linked in at build time. This appears to be a hopefully-not-too-fun case of "track down the difference between Arch and $other_distros"; anything that limits the search scope will probably be helpful to know.

I'm guessing I'll be playing fly-on-the-wall and watching to see what happens next from this point, but before that I briefly want to bring up and +1 the idea of having an obscure way to configure the heuristic in question here. I've long wanted to be able to customize what characters CTRL+Backspace will stop on, actually - it's been on my "get around to asking the Chrome guys about this one day" list for years. I'm aware of the Chromium team's reluctance to add configuration bits (and drown in the ensuing exponential profusion of test permutations :P), but maybe Chromium could look at GTK or other desktop settings (presuming the toolkit folks actually have their acts together and GTK does in fact have settings for things like this; I want to retain my sanity, so have admittedly not checked).

--

NEW INFORMATION:

I didn't catch this to begin with!

Whatever's upstream to CTRL+Backspace's behavior - presumably a word-splitting heuristic? - also impacts the behavior of double-click word selection.

Here's a demo - try double-clicking on either side of the decimal points in the test columns below. CTRL+Backspace will disregard (or regard) decimal points in the same situations double-click selection will select all or half of the following, respectively:

 Test          | "Arch Chromium" | Non-Arch Chromium/Chrome
               |                 |
 123456.789012 | All             | All
 123456.abcdef | Half            | Half
 abcdef.789012 | Half            | Half
 abcdef.ghijkl | All             | Half

"Half" or "All" describes whether double-clicking the "word" selects all of it or only up to the decimal point.

This behavior is demonstrated in the test video too.

As the behavior of CTRL+Backspace and doubleclick selection both seem to inherit from the same base problem, renaming the summary/subject to include the additional info may be a good idea. Something about word-splitting - but I don't have enough information to concretely rearticulate the title yet. I have no problem with someone else coming up with a good relevant title if they think it's a good idea.

---

Test details (included for completeness and for anyone who wants further info about what's shown in the video):

In the screencast in #3, CTRL+Backspace is shown to delete through "11.11", while it stops on the decimal point between "11.aa", "aa.11" and "aa.aa".

I found a number of Chrom{e,ium} versions that exhibited this exact behavior on my Arch box, even as they ran alongside the Arch version that behaved differently.

- Chromium base position 499422 (the same base position shown in the video, albeit with Chrome branding)

- A recent tip-of-tree - 547434 when I visited download-chromium.appspot.com the other day

- The current stable as reported by https://omahaproxy.appspot.com/history, 63.0.3239.132 / 508578

- The base position for Chromium 65.0.3325.162, the version I've been using for the last month or so; I ended up doing a "closest match" with this one, Omahaproxy mapped that version to 530369, but I could only find 530363 in commondatastorage, which turned out to be 65.0.3325.0

- The current stable version of Chrome (downloaded via chrome.com), 65.0.3325.181

- The latest Slackware Chromium package, 65.0.3325.181 (which launched just fine on Arch without any shared library issues): my attention was drawn to this issue in the first place because my secondary laptop (running an older Chromium release) was exhibiting the word-split behavior I was used to while Arch wasn't. I confirmed the very latest Slackware build of Chromium behaved the way I'd always experienced.

Initially I feared my research would stop here, but then I discovered https://archive.archlinux.org/.

This allowed me to step back through 64.0.3282.140, 64.0.3282.119-1, 64.0.3282.113-1 and 63.0.3239.84-1, as shown in the video.

At this point the change appears to be Arch-specific; the last good version is 63.0.3239.84-1 and the first bad version is 64.0.3282.113-1.

Deleted: ctrlbackspace.mp4 2.3 MB

	ctrlbackspace.mp4 2.3 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

The change in behavior seen with Arch's Chromium 64.0.3282.113-1 is due to the switch to system ICU. Building Chromium 65.0.3325.181 with bundled ICU makes it behave the same as Chrome.

The reason the bundled ICU behaves differently than the system one, is a patch that allows it to split "example.com" at '.' which is helpful for hostnames. [1]

Not sure what can be done here. I don't want to permanently switch Arch's Chromium to use the bundled ICU over a tiny issue such as this.

Perhaps jshin@ could suggest the best way to proceed here, or sees a solution that I can't. :)

[1] https://chromium.googlesource.com/chromium/deps/icu/+/d888fd2a1b/README.chromium#206

Ah, wow, that perfectly explains it! Thanks!

That makes the asterisked request for help/extra info in #4 irrelevant then.

Well, I now have the "engineering explanation" I was so curious about (and I conversely now know my system state is sane), so I'm in no hurry to push for this to be "fixed" per se. Taking time to work out how to resolve this may assist other distros headscratching over the same issue in future, too.

(In the worst case, I can either switch to going fishing in chromium-browser-snapshots - or, because Arch uses external ICU, I can just rebuild that, it looks like. I suddenly see that making the decision to _not_ bundle can sometimes be the right balance...)

CC'ing jshin@ as per Comment#6 hence requesting to help in further triaging and routing this to check @inhouse as this seems to be Arch linux specific which is not available with the team here as of now.

Thanks!

Since TE doesn't have arch linux machine, hence adding TE-NeedsTriageHelp label for further triage from dev team

jshin@ Could you please look into this machine.

Sorry for the above typo error

jshin@ Could you please look into this issue

The NextAction date has arrived: 2018-05-03

 Issue 474537  has been merged into this issue.

Issue occurs in both the omnibox and in web page content areas.