UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 YaBrowser/17.3.0.1785 Yowser/2.5 Safari/537.36

Steps to reproduce the problem:
Create a multiline Label (or a LabelButton) with font "Segoe UI 12px" (default font with delta = 0).

Assign a quite long text: "111 adsfasdfdddddddddddddddddddddddddddddddddfffffffe  e".

Put this button into a container view, with a vertical BoxLayout manager.

Set the width 277px.

Call Layout(), the manager will invoke GetHeightForWidth(277).

What is the expected behavior?
No DCHECK fault.
Somehow process too wide text correctly.

What went wrong?
DCHECK in HarfbuzzLineBreaker::AddLineSegment

        DCHECK_EQ(last_segment.char_range.end(), segment.char_range.start());

[18324:17264:0306/174119.936:FATAL:render_text_harfbuzz.cc(421)] Check failed: last_segment.char_range.end() == segment.char_range.start() (44 vs. 55)

Did this work before? N/A 

Chrome version: 57.0.2987.0  Channel: dev
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 24.0 r0

I've written a unittest (within ui/gfx/render_text_unittest.cc) that reproduces this bug.

TEST_P(RenderTextHarfBuzzTest, SomeDcheckFault) {
  RenderText* render_text = GetRenderText();
  render_text->SetHorizontalAlignment(gfx::ALIGN_TO_HEAD);
  render_text->SetDirectionalityMode(gfx::DIRECTIONALITY_FROM_TEXT);
  render_text->SetElideBehavior(gfx::NO_ELIDE);
  render_text->SetFontList(FontList("Segoe UI, 12px"));
  render_text->SetCursorEnabled(false);
  render_text->SetWordWrapBehavior(gfx::TRUNCATE_LONG_WORDS);
  render_text->SetMultiline(true);
  render_text->SetReplaceNewlineCharsWithSymbols(false);
  render_text->SetText(ASCIIToUTF16(
      "111 adsfasdfdddddddddddddddddddddddddddddddddfffffffe  e"));

  render_text->SetDisplayRect(gfx::Rect(0, 0, 277, 0));
  render_text->GetStringSize();
}