"Sampled usage" causes document.fonts.load to fail with DOMException

[tolmasky]

Description

Google appends an empty tracking font file apparently once every 1000 times. If you read this this bug, it will have you believe that the only side effect of this is a benign and ignorable warning stating Failed to decode downloaded font: https://fonts.gstatic.com/stats/FONT/normal/400.

Unfortunately, this is not the case. This empty font file also breaks the FontFaceSet.load API, causing it to throw a DOMException with the message "A network error occurred."

I have created a 100% reproducible test case by getting a copy of the CSS file for the google fonts request https://fonts.googleapis.com/css?family=Roboto&display=swap both with and without the additional sampling font-face. I then call the following in both instances and show that one succeeds while the other fails:

window.document.fonts.load("normal 400  100px 'Roboto'")

You can try them here:

1. Without sample (successful): https://bug-2345-vxsj8yuoiwrv.runkit.sh/?roboto-no-sample.css
2. With sample (failure): https://bug-2345-vxsj8yuoiwrv.runkit.sh/?roboto-with-sample.css

I will add that this fails in Chrome, Safari, and Firefox. So I believe this is probably "correct behavior" for FontFaceSet.load, and not a bug I should file on Chrome.

Results

This is making it incredibly difficult for our integration tests to pass, where around 300 tests end up calling code similar to this. Even at a frequency of 1 in 1000, that means our test suite fails around 25% of the time (1 - .999^300 = 0.259...). More importantly, this means our code is failing in the wild too.

This is a rather difficult failure to recover from too, since its hard to tell whether a real problem took place, or if its this "expected broken font". Additionally, even if you correctly identify the situation, its hard to "retry", as you'd probably have to dynamically remove the link tag and re-add it with a cache-busting query parameter.

Possible Solutions

1. Ideally, Google would either stop doing this, or at least do it in a way that doesn't break a web standards API. For example, perhaps return an actual one-character font-file instead of an empty response? Given that it is the space character, this should be pretty small?

2. I could use .load with a specific character (for example "a"), and I believe it will work. However, this would be a Google-specific hack in code that expects to work with a variety of font sources, and I have no way of knowing whether Google will always use U+20 as their fake character.

3. Unfortunately our best option right now seems to be to stop using Google fonts since we really don't have much control of this.

[rsheeter]

Thank you for the report; we will fix. I suggest either solution #2 or using a fixed copy of css response in integration tests in the interim.

[garretrieger]

We've decided to disable this for the time being. So you should no longer be seeing the sampling unicode ranges in CSS responses.