At normal scaling Issue is not seen on MacBook Air OS 10.12.5 on canary version: 62.0.3165.0. Probably Linux and Windows specific.

Issue is reproducible on 62.0.3165.0 of Windows-10.

Using per revision bisect providing bisect results below

Bisect Information:
--------------------
You are probably looking for a change made after 480346 (known good), but no lat
er than 480347 (first known bad).

Change Log URL: 
-----------------
https://chromium.googlesource.com/chromium/src/+log/38be868490ba34578d64c91e4eebdc44bef9b5cd..f9cc972addbcd3f856a0bfc595d1bf62c0824f82

timloh@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

Suspected CL looks unrelated.

Below is the bisect info.
========================

Unable to invoke builds using bisect-per-revision. Hence providing chromium bisect.

You are probably looking for a change made after 480348 (known good), but no lat
er than 480352 (first known bad).

Change Log URL: 
-----------------

https://chromium.googlesource.com/chromium/src/+log/10daf3e2c179c924705b3b4a1e2036562bcdc7ef..0f1c40a068b559512c192c0b88eb9d33a384142a

tapted@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review-Url: https://codereview.chromium.org/2942843002

Thanks!!

There are quite a few selection glitches for Telugu :/. The problem isn't really that CL, but the effects of these other glitches, which have been around for a while. At least since m59 -- see attached.

I'll take a look, but I don't think this needs to be treated as a regression.

Deleted: telugu_m59.mp4 1.8 MB

	telugu_m59.mp4 1.8 MB View Download

This is not a localization bug. Can't confirm that it's still relevant to the current English UI.

Just to update, Issue is still reproducible on the latest M-62 (62.0.3180.0) on Linux Ubuntu 14.04.

The problem seems to be a quirk of the grapheme iterator for some Telegu fonts. I actually hit a DCHECK in gfx::internal::TextRunHarfBuzz::GetGraphemeBounds:


    if (total > 1) {
      if (is_rtl)
        before = total - before - 1;
      DCHECK_GE(before, 0);
>     DCHECK_LT(before, total);
      const int cluster_width = cluster_end_x - cluster_begin_x;
      const int grapheme_begin_x = cluster_begin_x + static_cast<int>(0.5f +
          cluster_width * before / static_cast<float>(total));
      const int grapheme_end_x = cluster_begin_x + static_cast<int>(0.5f +
          cluster_width * (before + 1) / static_cast<float>(total));
      return RangeF(preceding_run_widths + grapheme_begin_x,
                    preceding_run_widths + grapheme_end_x);
    }

That DCHECK_LT fails with

render_text_harfbuzz.cc(760)] Check failed: before < total (2 vs. 2)

when trying to select over the word break

ok - i have a fix for this (I think) https://chromium-review.googlesource.com/706441

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2232611f7a7a7c9cc0c188cf25de236d3a4cde8b

commit 2232611f7a7a7c9cc0c188cf25de236d3a4cde8b
Author: Trent Apted <tapted@chromium.org>
Date: Thu Oct 12 13:16:47 2017

RenderText: Fix/improve/simplify selection of complex ligatures.

Currently, RenderTextHarfBuzz::GetSubstringBounds() intersects the
selection range with each text run, calculates widths of the selected
and unselected parts of the run, then highlights from one end or the
other of the run, depending on text direction.

The problem with this approach is that it's possible for multiple
graphemes to form a single ligature that is laid out vertically.
This means that *both* the selected and unselected parts of a text run
can occupy the same horizontal space; possibly the entire width of the
text run. This can result in a selection highlight appearing adjacent
to the selected range, since the entire width is used twice.

To fix, rather than using the width, preserve the start/end span
as reported by GetGraphemeBounds.

Bug:  747941 
Change-Id: I7002bfd14dda8e3fb0d251c033f8dadbae0c0133
Reviewed-on: https://chromium-review.googlesource.com/706441
Commit-Queue: Trent Apted <tapted@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508331}
[modify] https://crrev.com/2232611f7a7a7c9cc0c188cf25de236d3a4cde8b/ui/gfx/render_text_harfbuzz.cc
[modify] https://crrev.com/2232611f7a7a7c9cc0c188cf25de236d3a4cde8b/ui/gfx/render_text_harfbuzz.h
[modify] https://crrev.com/2232611f7a7a7c9cc0c188cf25de236d3a4cde8b/ui/gfx/render_text_unittest.cc