Switch the offset conversion routines from an "offsets point at characters"
worldview to an "offsets point between characters" worldview.
This more closely aligns with how the omnibox autocomplete code (which is what
this was originally written for) expects things to behave.
Direct fallout from this change:
* An input offset of 0 will always map to an output offset of 0.
* An input offset of (length of string) will always map to the length of the
output string, instead of npos.
* It's possible for multiple unique input offsets to map to a single non-npos
output offset, if they e.g. point to the start and end of a collapsed
sequence.
* Input offsets pointing into the middle of a completely-removed sequence may
not be set to npos if they fall on the boundaries of a subsequence processed
by the transformer. For example, when running FormatUrlWithOffsets() on
"http://user:pass@domain.com/" and directing it to omit both the scheme and
username/password, an input offset of "7" that points in between the scheme
and the username/password will be transformed to an output offset of 0
instead of npos.
Indirect fallout:
* A caller like SearchProvider::NavigationToMatch() will now mark certain
matches as "allowed to be default" that it didn't before. Specifically, if
the user's input string ends at the same point as the desired
|fill_into_edit|, the autocomplete offset will be calculated as (length of
string) instead of npos, and thus the match will be thought of as "inlinable"
and thus "allowed to be default".
BUG=284781
TEST=none
R=msw@chromium.org, willchan@chromium.org
Review URL: https://codereview.chromium.org/23619016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222426 0039d316-1c4b-4281-b951-d872f2087c98
CrOS-Libchrome-Original-Commit: cf7ca8aba2960aa5ba1b7accda08ba045a60c98d
3 files changed