devon@ Thanks for the issue...

Unable to reproduce the issue on latest chrome stable 70.0.3538.67 using Mac 10.13.6. Attaching screencast for reference.
Steps: 
---------
1. Launched reported chrome and opened https://jsfiddle.net/p0swdrbt/
2. Opened Dev tools > Disabled cache and turned on network throttling 
3. Refreshed the page to see font rendering behavior
As we are able to Task Manager.

@Reporter: Request you to retry this issue with fresh profile without any extensions & apps or reset all the flags and let us know if issue still persists. Could you please upgrade to latest chrome stable 70.0.3538.67, you can download latest chrome builds here:" https://www.chromium.org/getting-involved/dev-channel ". 
Let us know whether issue still persists.

Thanks.!

Deleted: 897539.mp4 2.4 MB

	897539.mp4 2.4 MB View Download

Hi -

Sorry if the steps weren't clear: you need to re-run the fiddle in order to see the behavior.

Please see the attached movie, which shows Chrome 70 first and Firefox 62 second.

thank you!

Deleted: swap.mp4 3.7 MB

	swap.mp4 3.7 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Also you need to turn on throttling by switching from 'online' to 'slow 3G'

Deleted: throttle.png 109 KB

	throttle.png 109 KB View Download

Deleted: options.png 32.0 KB

	options.png 32.0 KB View Download

Unable to reproduce the issue on mac 10.13.6 and 10.13.3 using chrome reported version #69.0.3497.100, latest stable #70.0.3538.67 and latest canary #72.0.3588.0 as per comment #3 and #5. Observed that the subset font is inlined, characters covered by it is always styled and never show in monospace as expected.
Attached a screen cast for reference.

devon@ - Could you please check the attached screen cast and please let us know if anything missed from our end. Also please check the issue on latest stable #70.0.3538.67 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 897539.mp4 2.6 MB

	897539.mp4 2.6 MB View Download

In comment #6, the cache was not disabled.

In order to reproduce, it's necessary that both the cache is disabled and the throttling is enabled. This is the only way to emulate the first load condition on a slow device when re-running the fiddle.

thanks for your help!

Deleted: cache.png 392 KB

	cache.png 392 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

A little more context on why this is important:

We're currently using FontTools [1] and the Google Noto Phase III fonts to generate application font subsets that get pre-loaded before the full Noto fonts. This allows all app text to render in Noto immediately, while user-generated content will render in default Sans-Serif until the full font is loaded.

The preferred stack looks like this:

  font-family: 'complete', 'subset', sans-serif;

Currently for Chrome in order to make this work, I need to specify the font stack as

  font-family: 'subset', 'complete', sans-serif;

However, since the subset might be missing information such as ligature tables, text might not display correctly even after the complete font is loaded since subset has priority.


[1] https://github.com/fonttools/fonttools
[2] https://github.com/googlei18n/noto-fonts/milestone/2

devon@ Thank for the feedback...

Able to reproduce the issue on reported chrome version 69.0.3497.100 also on latest chrome 72.0.3589.0 using Mac 10.13.6 and Ubuntu 14.04.  

Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged. 

Note: Issue not seen on Windows and inconsistent behavior seen on Ubuntu. Hence, adding linux OS label. 

Thanks! 

Thank you! I didn't realize it was OS-dependent - that's interesting.

For anyone else hitting this issue: we worked around it by using the Font Face Observer library to avoid referencing the full font until its been loaded:

  https://github.com/bramstein/fontfaceobserver

(This was necessary on older browsers anyway, but because of this issue we use it in newer browsers also.)

drott@, could you take a look?

It seems FontFallbackIterator does not attempt to load / use the second custom font if the first custom font is loading and its unicode range is a superset of second font's.

https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/fonts/font_fallback_iterator.cc?l=194&rcl=566701e52aff09f58bf6d76b90393589a8f5e06e