This issue does not reproduce on Chromium 47.
It's introduced since Chromium 48.

Does it occur on multiple sites: YES

Is it a problem with a plugin? NO

Did this work before?  Yes. Chroumium 47 works well.

This issue seems a regression of 
https://chromium.googlesource.com/chromium/src/+/9f6a2b03ccb7091804f173b70b5facff7dffbd61

Able to reproduce the issue on Linux Ubuntu 14.04 and Mac 10.11.5 using chrome version 51.0.2704.84 and canary 53.0.2763.0.
This is regression issue broken in M48.Please find the bisect information as below

Narrow Bisect
=================
Good:: 48.0.2544.0  ---  (official build 355679)
Bad:: 48.0.2545.0  ---   (official build 355918)

Unable to provide tool bisect as it is giving error saying "not enough builds to bisect".Hence providing manual change log.

Change Log::
===============
https://chromium.googlesource.com/chromium/src/+log/48.0.2544.0..48.0.2545.0?pretty=fuller&n=10000

Unable to find the exact suspect though suspecting this might be related to change 
https://codereview.chromium.org/1421113002

joelo@ Could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue.

Thanks,

Snapshot build:

Last good: 355785
Chromium	48.0.2545.0 (Developer Build) (64-bit)
Revision	b270236865580fbedf0eb24d6610a2051b6200a3-refs/heads/master@{#355785}
OS	Linux 
Blink	537.36 (@b270236865580fbedf0eb24d6610a2051b6200a3)
JavaScript	V8 4.8.133
Flash	(Disabled)
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2545.0 Safari/537.36
Command Line	./chrome --no-sandbox --flag-switches-begin --flag-switches-end
Executable Path	/home/xxxxxx/Desktop/chrome-linux/chrome
Profile Path	/home/xxxxxx/.config/chromium/Default
Variations	775ebbd7-3f4a17df
97dfc274-3f4a17df
4ea303a6-3f4a17df
5c3cc7b1-3f4a17df


First bad: 355790
Chromium	48.0.2545.0 (Developer Build) (64-bit)
Revision	304d20954b50382395b4ed702e8571f6da71b0f6-refs/heads/master@{#355790}
OS	Linux 
Blink	537.36 (@304d20954b50382395b4ed702e8571f6da71b0f6)
JavaScript	V8 4.8.135.2
Flash	(Disabled)
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2545.0 Safari/537.36
Command Line	./chrome --no-sandbox --flag-switches-begin --flag-switches-end
Executable Path	/home/xxxxxx/Desktop/chrome-linux/chrome
Profile Path	/home/xxxxxx/.config/chromium/Default
Variations	775ebbd7-3f4a17df
97dfc274-3f4a17df
4ea303a6-3f4a17df
5c3cc7b1-3f4a17df


Changes in this two version
https://chromium.googlesource.com/chromium/src/+log/6d939d13f77b157797ff9691076bc3c69f4d96a2?n=12


This issue is probably a regression of
https://chromium.googlesource.com/chromium/src/+/9f6a2b03ccb7091804f173b70b5facff7dffbd61

Moving this nonessential bug to the next milestone.

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

This bug impact many Burmese websites.

The input string in the test case starts with ေ which leads our grapheme cluster based fallback algorithm to think that the leading ‘  ေ and are one cluster. This cluster can't be shaped with a Burmese font or with the fallback font, since neither has a complete glyph for the grapheme. 

However, I need to investigate further: the extractShapeResults code then continues to group the input from the beginning until the next run boundary and only finds the last resort font, instead of resuming with the next cluster and dropping only the first one.

Do you have some example of where this affects Burmese sites? I am not sure I can judge this correctly, but the example in the test does not seems not that realisitic to me, as it has many subsequences of where a combining mark does not match up with any base character.

If for example, the input string is modified to not start with a combining mark, like so:
‘ရွး  ‘ရွး
this renders correctly in Chrome.

Here is another test case.

http://bluemyanmar.blogspot.in/2014/05/blog-post_11.html?m=1

Fix proposal up in https://codereview.chromium.org/2530153002

Re #13, can you help identifying whether this is a well formed input? I'd like to get a better understanding of how common is the case where the text starts with spacing  marks, right after a punctuation character.

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

commit d9280a5e951415e1b2c6c7958adda19b731a99fa
Author: drott <drott@chromium.org>
Date: Mon Nov 28 16:35:20 2016

Improve fallback for Burmese with leading punctuation + spacing mark

 Issue 618178  describes an example where a Burmese text run starts with a
leading punctuation character followed by a combining spacing mark. This
grapheme cannot be shaped with the default font, since Times for example
cannot display the combination of a left quote with a Burmese combining
mark. Our fallback code attempts to find a fallback font based on the
first character at the beginning of an extracted unshaped sub-run, which
does not lead to finding a font suitable for Myanmar text in this case.
So in a way it runs into a fallback trap, where no fallback hint helps
to find the right fallback font and the whole run ends up as notdef
glyphs.

This CL attempts to resolve this by looking for a better fallback hint
character, which is not script common or inherited, if such is
available. This improves the situation for the Burmese text from the
issue report.

In addition, as a better fix we should give higher importance to the
locale information in font fallback, filed as issue 668706.

BUG= 618178 
R=eae,kojii,behdad

Review-Url: https://codereview.chromium.org/2530153002
Cr-Commit-Position: refs/heads/master@{#434665}

[modify] https://crrev.com/d9280a5e951415e1b2c6c7958adda19b731a99fa/third_party/WebKit/LayoutTests/NeverFixTests
[add] https://crrev.com/d9280a5e951415e1b2c6c7958adda19b731a99fa/third_party/WebKit/LayoutTests/inspector-protocol/layout-fonts/fallback-myanmar.html
[modify] https://crrev.com/d9280a5e951415e1b2c6c7958adda19b731a99fa/third_party/WebKit/LayoutTests/inspector-protocol/layout-fonts/resources/layout-font-test.js
[add] https://crrev.com/d9280a5e951415e1b2c6c7958adda19b731a99fa/third_party/WebKit/LayoutTests/platform/mac/inspector-protocol/layout-fonts/fallback-myanmar-expected.txt
[add] https://crrev.com/d9280a5e951415e1b2c6c7958adda19b731a99fa/third_party/WebKit/LayoutTests/platform/win/inspector-protocol/layout-fonts/fallback-myanmar-expected.txt
[add] https://crrev.com/d9280a5e951415e1b2c6c7958adda19b731a99fa/third_party/WebKit/LayoutTests/platform/win7/inspector-protocol/layout-fonts/fallback-myanmar-expected.txt
[modify] https://crrev.com/d9280a5e951415e1b2c6c7958adda19b731a99fa/third_party/WebKit/Source/platform/fonts/FontFallbackIterator.cpp
[modify] https://crrev.com/d9280a5e951415e1b2c6c7958adda19b731a99fa/third_party/WebKit/Source/platform/fonts/FontFallbackIterator.h

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

commit 1b8f4236e2dbf4e07bf0171300003168633b8660
Author: mek <mek@chromium.org>
Date: Mon Nov 28 21:08:42 2016

Revert of Improve fallback for Burmese with leading punctuation + spacing mark (patchset #3 id:30009 of https://codereview.chromium.org/2530153002/ )

Reason for revert:
This seems to be causing test failures for fast/text/international/text-spliced-font.html on https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win10/builds/17622

Original issue's description:
> Improve fallback for Burmese with leading punctuation + spacing mark
>
>  Issue 618178  describes an example where a Burmese text run starts with a
> leading punctuation character followed by a combining spacing mark. This
> grapheme cannot be shaped with the default font, since Times for example
> cannot display the combination of a left quote with a Burmese combining
> mark. Our fallback code attempts to find a fallback font based on the
> first character at the beginning of an extracted unshaped sub-run, which
> does not lead to finding a font suitable for Myanmar text in this case.
> So in a way it runs into a fallback trap, where no fallback hint helps
> to find the right fallback font and the whole run ends up as notdef
> glyphs.
>
> This CL attempts to resolve this by looking for a better fallback hint
> character, which is not script common or inherited, if such is
> available. This improves the situation for the Burmese text from the
> issue report.
>
> In addition, as a better fix we should give higher importance to the
> locale information in font fallback, filed as issue 668706.
>
> BUG= 618178 
> R=eae,kojii,behdad
>
> Committed: https://crrev.com/d9280a5e951415e1b2c6c7958adda19b731a99fa
> Cr-Commit-Position: refs/heads/master@{#434665}

TBR=behdad@chromium.org,eae@chromium.org,kojii@chromium.org,drott@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 618178 

Review-Url: https://codereview.chromium.org/2532253002
Cr-Commit-Position: refs/heads/master@{#434719}

[modify] https://crrev.com/1b8f4236e2dbf4e07bf0171300003168633b8660/third_party/WebKit/LayoutTests/NeverFixTests
[delete] https://crrev.com/5c30282c70ec5f7f92129589fbbc84fef5738454/third_party/WebKit/LayoutTests/inspector-protocol/layout-fonts/fallback-myanmar.html
[modify] https://crrev.com/1b8f4236e2dbf4e07bf0171300003168633b8660/third_party/WebKit/LayoutTests/inspector-protocol/layout-fonts/resources/layout-font-test.js
[delete] https://crrev.com/5c30282c70ec5f7f92129589fbbc84fef5738454/third_party/WebKit/LayoutTests/platform/mac/inspector-protocol/layout-fonts/fallback-myanmar-expected.txt
[delete] https://crrev.com/5c30282c70ec5f7f92129589fbbc84fef5738454/third_party/WebKit/LayoutTests/platform/win/inspector-protocol/layout-fonts/fallback-myanmar-expected.txt
[delete] https://crrev.com/5c30282c70ec5f7f92129589fbbc84fef5738454/third_party/WebKit/LayoutTests/platform/win7/inspector-protocol/layout-fonts/fallback-myanmar-expected.txt
[modify] https://crrev.com/1b8f4236e2dbf4e07bf0171300003168633b8660/third_party/WebKit/Source/platform/fonts/FontFallbackIterator.cpp
[modify] https://crrev.com/1b8f4236e2dbf4e07bf0171300003168633b8660/third_party/WebKit/Source/platform/fonts/FontFallbackIterator.h

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

commit 04f5eaaa234b142614e315f3ccd94f4e55015f10
Author: drott <drott@chromium.org>
Date: Tue Nov 29 10:20:22 2016

Improve fallback for Burmese with leading punctuation + spacing mark

Reland after revert in 1b8f4236e2dbf4e07bf0171300003168633b8660,
previous CL https://codereview.chromium.org/2530153002/
Previously failing Win10 test needs a rebaseline.

 Issue 618178  describes an example where a Burmese text run starts with a
leading punctuation character followed by a combining spacing mark. This
grapheme cannot be shaped with the default font, since Times for example
cannot display the combination of a left quote with a Burmese combining
mark. Our fallback code attempts to find a fallback font based on the
first character at the beginning of an extracted unshaped sub-run, which
does not lead to finding a font suitable for Myanmar text in this case.
So in a way it runs into a fallback trap, where no fallback hint helps
to find the right fallback font and the whole run ends up as notdef
glyphs.

This CL attempts to resolve this by looking for a better fallback hint
character, which is not script common or inherited, if such is
available. This improves the situation for the Burmese text from the
issue report.

In addition, as a better fix we should give higher importance to the
locale information in font fallback, filed as issue 668706.

BUG= 618178 
TBR=eae,kojii,behdad

Review-Url: https://codereview.chromium.org/2539733002
Cr-Commit-Position: refs/heads/master@{#434944}

[modify] https://crrev.com/04f5eaaa234b142614e315f3ccd94f4e55015f10/third_party/WebKit/LayoutTests/NeverFixTests
[modify] https://crrev.com/04f5eaaa234b142614e315f3ccd94f4e55015f10/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/04f5eaaa234b142614e315f3ccd94f4e55015f10/third_party/WebKit/LayoutTests/inspector-protocol/layout-fonts/fallback-myanmar.html
[modify] https://crrev.com/04f5eaaa234b142614e315f3ccd94f4e55015f10/third_party/WebKit/LayoutTests/inspector-protocol/layout-fonts/resources/layout-font-test.js
[add] https://crrev.com/04f5eaaa234b142614e315f3ccd94f4e55015f10/third_party/WebKit/LayoutTests/platform/mac/inspector-protocol/layout-fonts/fallback-myanmar-expected.txt
[add] https://crrev.com/04f5eaaa234b142614e315f3ccd94f4e55015f10/third_party/WebKit/LayoutTests/platform/win/inspector-protocol/layout-fonts/fallback-myanmar-expected.txt
[add] https://crrev.com/04f5eaaa234b142614e315f3ccd94f4e55015f10/third_party/WebKit/LayoutTests/platform/win7/inspector-protocol/layout-fonts/fallback-myanmar-expected.txt
[modify] https://crrev.com/04f5eaaa234b142614e315f3ccd94f4e55015f10/third_party/WebKit/Source/platform/fonts/FontFallbackIterator.cpp
[modify] https://crrev.com/04f5eaaa234b142614e315f3ccd94f4e55015f10/third_party/WebKit/Source/platform/fonts/FontFallbackIterator.h

The patch has been reverted.

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

commit c19343f08099ecb7634cf5458c76af4067bbc4c4
Author: Rebaseline Bot <blink-rebaseline-bot@chromium.org>
Date: Wed Nov 30 04:04:57 2016

Auto-rebaseline for r434944

https://chromium.googlesource.com/chromium/src/+/04f5eaaa2

BUG= 618178 
TBR=drott@chromium.org

Review URL: https://codereview.chromium.org/2529393005 .

Cr-Commit-Position: refs/heads/master@{#435131}

[modify] https://crrev.com/c19343f08099ecb7634cf5458c76af4067bbc4c4/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/c19343f08099ecb7634cf5458c76af4067bbc4c4/third_party/WebKit/LayoutTests/platform/win/fast/text/international/text-spliced-font-expected.png

Re #21, the commit in #18 is sticking. Feel free to re-test.