Over to drott for clarification as he's tweaked the behavior here quite a bit lately.

Thanks for the report, Mateusz. I can reproduce the first set of reproduction steps for the https://www.theguardian.com/science/grrlscientist/2012/aug/07/3 url and on Windows, I see the result as in your "Guardian font Chromium bug.PNG" screenshot, however, pasting into Google fonts shows a different result for me (showing â + .notdef mark, keeping all words rendered in Roboto). 

Do you know more about the sequence of font loading on the guardian grrlscientist page? Does this roughly follow the font loading strategy in https://github.com/guardian/frontend/blob/master/common/app/templates/inlineJS/blocking/loadFonts.scala.js ? I suspect Chrome may fail to invalidate the word cache for the page and keep words in it that have been rendered with the fallback font, Times New Roman, for the sentence in question. 

When I try to create a static reproduction, I do not succeed, probably because there is a timing/sequence of events aspect to this problem. 

Hello! Thank you very much for looking into it and I’m sorry I wasn’t clear.

Revised steps to repro problems 1 & 2:
1b. Go to https://fonts.google.com/
2b. Right click and Inspect a frame showing a font supporting U+00E2, but not supporting U+0309, e.g. Roboto.
3b. Right click on an Element containing the frame’s code in the DevTools and click Edit HTML.
4b. At the end a string of text, paste “â” (LATIN SMALL LETTER A WITH CIRCUMFLEX (as â)).
3b. Right click on an Element containing the frame’s code in the DevTools and click Edit HTML.
5b. Immediately after “â”, paste COMBINING HOOK ABOVE (as ̉).
[see attached GIF]

I’m code-dumb, so can rely specific questions about font loading to my colleagues, but I know that the default font loading mechanism uses base64 json strings kept in local storage. However, you can reproduce the problem also using an emergency, completely separate font loading mechanism that loads the fonts directly – by accessing https://www.theguardian.com/science/grrlscientist/2012/aug/07/3 when Chrome is set to NOT Allow sites to save and read cookie data (chrome://settings/content/cookies).

Both problems manifest themselves on Windows, OSX and Android. In Opera as well.

Let me know if I can help any more!

Thank you.

Regards
Mateusz

Deleted: Chrome combining mark repro.gif 1.8 MB

	Chrome combining mark repro.gif 1.8 MB View Download

Right, thanks, I missed the initial step 3a, of pasting into "Edit HTML" in DevTools, and instead I pasted into the contenteditable Google Fonts sample box directly. Now I can reproduce the Google Fonts repro steps as well. I'll investigate and see if I can further reduce the issue.

Simulating what the Guardian's font loader [1] does, I have a reproduction now (see guardianfonts.html). If I read the code right, the loader is inline executed and for newly arriving fonts inserting @font-face rules to style elements using '$0.innerHTML = <cssFromXHRFetch>'. The font or URL does not seem to matter, as long as it is a url() network resource.

For @font-face rules that are injected in this way, something goes wrong in the interaction between shaping/FontFallbackIterator and font loading. If I had to speculate, perhaps their load status is not marked correctly?

[1] https://github.com/guardian/frontend/blob/master/common/app/templates/inlineJS/blocking/loadFonts.scala.js

Deleted: guardianfonts.html 425 bytes

guardianfonts.html 425 bytes View Download

Correction, even when loading the Roboto latin face through adding a new style element, loading it through the FontFace API, or simply loading it via an inline @font-face, this can be reproduced. 

Deleted: guardianfonts2.html 262 bytes

guardianfonts2.html 262 bytes View Download

Deleted: roboto_shaping.png 14.1 KB

	roboto_shaping.png 14.1 KB View Download

This reproduces even when @font-face { src: local(Roboto); ... } is used, where the font face is resolved immediately. I think this is not a font loading issue.

Deleted: guardianfonts3.html 323 bytes

guardianfonts3.html 323 bytes View Download

Candidate fix work-in-progress in https://chromium-review.googlesource.com/c/chromium/src/+/657977

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

commit 83821ae6fdc08f0ed0dbca13ad20d90fca7f3050
Author: Dominik Röttsches <drott@chromium.org>
Date: Tue Sep 26 09:48:43 2017

Fix incorrect font used in prefix of run ending in fallback grapheme

When a run ended in a grapheme cluster consisting of a least two
characters, and this grapheme resulted in not being shaped with the
current font and needed fallback, then the full run from the beginning
was incorrectly rendered in the fallback font. This is because one state
transition between shaped and not shaped was not recognized, as the
last_change_position had been advanced too far.

To fix this, I clarified the shaping loop and moved the logic for
commiting glyphs and queueing characters for reshaping into separate
functions. When reaching the end of the glyph run, transitions between
shaped or unshaped are detected for the last grapheme cluster and added
to the ShapeResult or the reshaping queue accordingly.

       inspector-protocol/layout-fonts/prefix-fallback-multi-character-grapheme.js
       svg/text/combining-character-queries-expected.svg

Bug:  758380 
Tests: EmojiZWJSequence in HarfBuzzShaperTest.cpp,
Change-Id: I95d536c488ac602cb4bdfd4e1ac4a729f92b1462
Reviewed-on: https://chromium-review.googlesource.com/657977
Commit-Queue: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504327}
[add] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/LayoutTests/flag-specific/run-layout-test/platform/linux/inspector-protocol/layout-fonts/prefix-fallback-multi-character-grapheme-expected.txt
[add] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/LayoutTests/inspector-protocol/layout-fonts/prefix-fallback-multi-character-grapheme.js
[modify] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/LayoutTests/platform/linux/fast/text/international/complex-joining-using-gpos-expected.png
[modify] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/LayoutTests/platform/linux/svg/text/combining-character-queries-expected.png
[modify] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/LayoutTests/platform/linux/svg/text/combining-character-queries-expected.txt
[add] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/LayoutTests/platform/mac/inspector-protocol/layout-fonts/prefix-fallback-multi-character-grapheme-expected.txt
[add] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/LayoutTests/platform/win/inspector-protocol/layout-fonts/prefix-fallback-multi-character-grapheme-expected.txt
[modify] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/LayoutTests/platform/win/svg/text/combining-character-queries-expected.png
[modify] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/LayoutTests/platform/win/svg/text/combining-character-queries-expected.txt
[modify] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaper.cpp
[modify] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaper.h
[modify] https://crrev.com/83821ae6fdc08f0ed0dbca13ad20d90fca7f3050/third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaperTest.cpp

Mateusz, thanks for the report, this has been very helpful.

Dominik, thank you so much for fixing this!