Judging from those two screenshots, the issue seems to be that "i" characters are displayed as squares,  jainabhishek@ can you confirm that this is the case in the other reports?

I can reproduce with 

data:text/html;charset=utf-8,%3Cspan%20lang%3D%22tr%22%3Ei%3C%2Fspan%3E

under Windows 10
using 51.0.2673.0 canary, or 49.0.2623.75 beta.

The tr lang attribute on the text causes shaping of the "i" character to fail. I will investigate further.

Not reproducible under Windows 8.1 when using this reduction.

With a Windows build of HarfBuzz git master:
$ ./hb-shape.exe /cygdrive/c/Windows/Fonts/arial.ttf i --language=tr
[gid3464=0+455]

$ ./hb-shape.exe /cygdrive/c/Windows/Fonts/arial.ttf i
[gid76=0+455]

Where looking at glzph id gid3464 in the font, it is just a component reference to the glyph for i:
    <TTGlyph name="glyph03464" xMin="136" yMin="0" xMax="316" yMax="1466">
      <component glyphName="i" x="0" y="0" flags="0x204"/>
    </TTGlyph>

But for some reason, we can't render a glyph for it and a box is shown instead.

CC bungeman@

In my reproduction I can confirm that disabling DirectWrite makes the Arial and Times Turkish "i" glyph appear. Screenshots attached.

There does seem to be an issue in rendering glyphs correctly through DirectWrite.

Deleted: failing_direct_write_on.png 101 KB

	failing_direct_write_on.png 101 KB View Download

Deleted: working_direct_write_disabled.png 76.4 KB

	working_direct_write_disabled.png 76.4 KB View Download

With 49.0.2623.75 and 
chrome.exe --force-fieldtrials=DirectWriteFontProxy/UseDirectWriteFontProxy/
it renders correctly.

Deleted: field_trial_working.PNG 52.4 KB

	field_trial_working.PNG 52.4 KB View Download

We should try and find a bisect range, now that there is a viable repro.

kulshin@ - It seems almost certain this was your change. So, we need you to diagnose and come up with a solution ASAP so we can unblock the stable push.

That stated, it looks like we can just push the new proxy trial to 100% to fix the rendering issue and continue pushing the update. So, maybe that's the best solution?

Do you happen to know the font format for your glyphs? DirectWrite does not support all font formats that are supported by GDI.

http://blogs.msdn.com/b/text/archive/2009/04/13/directwrite-questions-and-answers.aspx
DirectWrite does not support bitmap or vector .FON font files, and DirectWrite does not support Adobe Type 1 .PFM/.PFB font files.

Re #13, In the reproduction I used for the screenshots:
data:text/html;charset=utf-8,%3Cspan%20style%3D%22font-family%3AArial%3B%20font-size%3A200px%3B%22%20lang%3D%22tr%22%3Ei%3C%2Fspan%3E%3Cspan%20style%3D%22font-family%3ATimes%3B%20font-size%3A200px%3B%22%20lang%3D%22tr%22%3Ei%3C%2Fspan%3E

the fonts are Windows' built-in Times New Roman and Arial, glyph shapes in those fonts are in the OpenType glyf table, in TrueType outline format, which should render fine in GDI and DirectWrite.

kulshin@, please let me know once you look into this issue, if you have a fix soon enough. If not, we may need to disable by default till we find a fix. I am raising the priority to P0, until the stable push is unblocked/we decide on a solution otherwise.

kulshin@ - Which DW implementation is enabled by default on canary and dev channels?

It's under field trial. Default is the font cache path, with 10% experiment using the proxy.

Let me perhaps emphasize that I am fairly certain this is not a fallback issue: Both Times and Arial have a glyph for "i" (id 76) and a glyph substitution which replaces the regular "i" (gid76) with another glyph (gid3464) when the language is Turkish. In the font file, this glyph ID 3464 then references the contours of the regular i, but it is a separate glyph. These glyphs are rendered in the working cases: When either DWrite is off, or when the new proxy is active. Used fonts in Inspector shows Arial and Times respectively, whether the glyph is rendered as "i" or ".notdef".

kulshin@, jschuh@, any updates here? Do we have any ideas on what could be going on or a fix in sight, maybe?

I also tried copying the arial.ttf and times.ttf fonts to Mac, create Turkish lang="tr" test  content and on Mac the glyphs from these fonts are shown in Chrome. 

I wonder if deleting the chrome DWriteFontCache could have an effect. If someone can repro this, could you try deleting the cache - it's in %localappdata%/google/chrome/userdata/profile/ChromeDWriteFontCache.

The finch trial has been pushed to 100% (as per kulshin@ and jschuh@) and we are ramping up M49 stable to 10%. We will watch till end of day tomorrow and make a call on further steps, unless we hit something before that. Thank you all for your help, repro, attempts to repro and responses!

Ramped up stable AU to 10% - Windows & Mac.

Making this bug public

Interesting, I tried #23 on my repro box and this fixes the rendering. I confirmed DirectWrite was on, and the previous rendering before removing the cache were .notdef boxes.  - so would that indicate there was some sort of corruption in the ChromeDWriteFontCache?
When I move the suspicious ChromeDWriteFontCache back in place, the boxes appear again. 

I uploaded the file here: https://drive.google.com/a/chromium.org/file/d/0B3pBEBW4fvexR01wdl9Mc1QwalE/view?usp=sharing

Somehow I was unable to reproduce this on the latest canary(51.0.2673.0) on Windows-10 (Direct Write enabled/ Time New roman as Standard Font under chrome://settings/fonts) or Mac OS 10.11.3 with 

1. data:text/html;charset=utf-8,<span%20style%3D"font-family%3AArial%3B%20font-size%3A200px%3B"%20lang%3D"tr">i<%2Fspan><span%20style%3D"font-family%3ATimes%3B%20font-size%3A200px%3B"%20lang%3D"tr">i<%2Fspan>

2. data:text/html;charset=utf-8,<span%20lang%3D"tr">i<%2Fspan>

3. Tried by changing the browser language to turkish and navigated to http://www.google.com/intl/tr/mail/help/about.html as well but didn't observe any square box rendering on the page. 

Removing the Needs-Bisect label as per C#12.But please let us know if anything is being missed here to repro this.

drott@, are you still able to repro the issue after a restart? The finch trial should be in effect at 100% now, and we are hoping this fixes the issue.

drott@ just tried this out and confirmed that he is not able to repro the issue on .87 after a restart, even if he copies in the corrupt cache file.

Not reproducible with .87 with the default field trial settings. (Reproducible only if the corrupt DWrite font cache in the profile folder and force disabling the field trial.)

Re #28: You can try quitting chrome, copying the corrupt DWrite fontcache file into your profile: C:\Users\<YourUserAccount>\AppData\Local\Google\Chrome\User Data\Default\
Then start Chrome with:
chrome.exe --force-fieldtrials=DirectWriteFontProxy/UseDirectWriteFontCache/
to _disable_ the field trial.

Not reproducible on win10 chrome version 49.0.2623.87 with default field trial settings. Tried navigating to www.google.com.tr, http://www.google.com/intl/tr/mail/help/about.html and data:text/html;charset=utf-8,<span%20lang%3D"tr">i<%2Fspan>     observed no square boxes displayed

however reproducible following the steps in comment #31 placing the corrupt DWrite font cache file in the profile folder and force disabling the field trial

Removing the Needs-TestConfirmation.

drott@, Could you please confirm if the issue can be closed?

Yes, we can close this one, however the underlying problems are not completely solved, now we have missing last resort font information instead, see issue 561873.

 Issue 593571  has been merged into this issue.

Hello!
It looks like ChromeDWriteFontCache is invalidated during upgrade from Win 7 to Win 10.
Did you fix this bug by disabling cache? Does it hurt performance?
Could you please tell if the issue 561873 is related? I don’t have access to it.

This was fixed by disabling the cache and switching to a new system to load font data. In the new system fonts are only loaded when needed (instead of loading all the font headers in the system), so that actually comes out to a performance win.

561873 is likely related, but we still haven't determined a definite root cause.

It's good!

Did you check the suggestion about Win7 -> Win10 upgrade in 561873?
Or do you have another suggestion?

I don't think issue 561873 is caused by upgrade, since the crash also appears on win7, and is more likely to occur after disabling the font cache. So far I haven't found any definitive correlation, but feel free to let me know if you have any evidence to support any particular hypothesis.

Oh, issue 561873 is about crash.
I think it is about square glyph too, sorry.