Unable to reproduce this issue on Windows 10 with chrome version #63.0.3239.132

Attaching the screen-cast for reference.

thammaknot@ Could you look into it and let us know any steps i have misssed whie reproducing the scenario.

Adding the fonts and localization team for their inputs...

Deleted: 813534.mp4 1.3 MB

	813534.mp4 1.3 MB View Download

I don't know how Chrome decides when to autocomplete (or not)...
It may actually depend on your account?

In any case, in the video, you typed in gibberish...so it's imaginable that none of those would produce any legitimate auto complete.

Could you try the letters I described?

If you typed it in the sequence as described in my new screenshot, and there's no autocomplete, then make sure that there is nothing disabling autocompletion.

If that still doesn't work, I don't know how I would force autocompletion & highlight in Chrome. They are necessary to reproduce this bug.

Deleted: Screen Shot 2018-02-20 at 1.14.56 PM.png 657 KB

	Screen Shot 2018-02-20 at 1.14.56 PM.png 657 KB 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

Thanks for the report.  Sadly, this is a known issue.  The omnibox doesn't know how to highlight/select text when an autocompletion combines (as with diacriticals) to text already entered.

I don't think this is the same issue as 702716; that issue is about painting when a selection terminates amid a grapheme cluster (or multi-char glyph?).

This issue seems to be about autocomplete setting a selection that includes the entire grapheme cluster instead of an intended portion thereof (ie. just the second diacritic). In other words, it sounds like the selection range applied from autocomplete should be logical indices 4-n, but actually winds up with logical indices 2-n. Perhaps this happens because RenderText determines that 4 is not a valid cursor position, and so adjusts the selection range to include the entire grapheme cluster). For sure, pasting "เครื่อง" in a views textfield and moving the cursor jumps over the entire "รื่" cluster. In the other issue, we certainly have a selection that ends in the middle of a grapheme cluster (or multi-char glyph), but here we are perhaps unable to set a selection that ends in the middle of this grapheme cluster (or multi-char glyph). De-duping

This seems like a pretty bad usability issue; I'm sorry that it's been around so long.

Yes. What msw@ described is quite accurate.
It's been around for so long...like I-don't-even-remember-since-when long. 
It's indeed a huge usability issue.

Any chance we could get a fix for this soon?
Thank you!

Hi,

Thank you for reporting. 
It seems like it is more of a functional case, like user input.
Looping in the Engineering Team for assistance, if any.

Regards!

Copying an offline discussion here (hope that's okay, Mark!):

===========================
mpearson:

I think before fixing it, you need to figure out what behavior you want.

If a user types "a" and the omnibox system would like to inline autocomplete to "abc", where "ab" is a combined character (like a diacritical), what do you want to happen?  You cannot have this inline autocompletion selection because we cannot select half of a combined character.  I don't think part is possible to fix (msw@) correct me if I'm wrong.

Right now we end up showing "abc" as an inline autocompletion, i.e., put the cursor before the combining character.

You can imagine putting the cursor after the combining character, i.e., revising the user text to "ab" (even though they didn't type the "b") and showing "c" as an inline autocompletion.  That sounds wrong too.

If it's not possible to fix mid-character selections, then you're going to have to make sure that no inline autocompletion happens when the beginning of an inline autocompletion is something that combines with the end of the trailing text.  That's a ranking change.

===========================
msw:

It should be possible to select half of a combined character... It might even be a fairly simple (or hacky) workaround to allow selections to encompass the autocompleted diacritic without encompassing the entire grapheme cluster (or whatever the proper term is for the base-character-plus-diacritics combo here), ie. select "bc", but not "a".

To go down that route: I believe gfx::RenderText[HarfBuzz] or views::Textfield is widening the selection range when the ends are not valid cursor positions (see RenderText::IsValidCursorIndex and IsValidLogicalIndex). Find out where that happens; it's possible we could leave the indices as-is if they are valid logical indices, even if they aren't valid cursor indices. Otherwise, we could add a RenderText API to allow selections with more permissive range indices. I'm not sure what we can do about rendering this partial selection, perhaps that's where we'd need to expand the visual selection bounds to encompass the entire cluster?

Otherwise, I'd reluctantly pursue Mark's suggestion of avoiding inline autocompletions that begin with diacritics and combine with the trailing input string, etc. (we should be able to support this...)

The suggestion from msw@ (selection only includes diacritics) makes sense to me.

If not, then I agree that avoiding inline autocompletions like this is an acceptable solution.

Thank you for looking into this.
Please let me know if I can help test or provide more information in any way.

Unable to reproduce the issue on Windows 10 with chrome  #63.0.3239.132, while typing the thai alphabets as provided in comment #0

Attaching the screen-short for reference.

Hi kkaluri@,

The screenshot shows the full query (which is also badly misspelled by the way). The correct full query is "เครื่องทำน้ำอุ่น".

To trigger this bug, you only need to type in the first 4 characters: "เครื".

At least on my machine, once these 4 chars are entered, Chrome will instantly autocomplete it into "เครื่องทำน้ำอุ่น".

See the screenshot attached to my first comment.

Please let me know if there is anything I can do to help here.

Any objections to removing RVG? I want to point people who were following the Cocoa version of this bug here.

> Any objections to removing RVG?
No objections.