They are only used by FontCache::systemFallbackForCharacters() where a direct FcFontMatch provides the same results in a more efficient way. This produces better results in 3 tests: fast/text/international/bidi-LDB-2-CSS.html fast/text/international/bidi-LDB-2-HTML.html fast/text/international/bidi-LDB-2-formatting-characters.html For some reason when using the fallbacks to get the system fallback font the non-bold font is selected for H1, while using FcFontMatch returns the right bold font. I can only reproduce this inside the testing environment, so maybe it's not actually a bug, but in the best case removing the fallbacks doesn't regress.
Ok, I know why. When using the fallbacks we use FcFontSort() to ge the list of patterns for all fonts in the system, but sorted by better matching the given pattern. But we are passing True for the trim parameter, which for some reason makes dejavu sans bold to not be included in the list. That's why the best match is not bold. Passing False to FcFontSort also makes the test use the bold font, but then, again, it's effectively the same than using FcFontMatch directly. Another interesting thing is that the pattern we use has the default font settings, so it's always using dejavu sans, I would expect in the tests to end up using liberation. And Liberation is probably the first one in the sorted set, but since out pattern has dejavu it ends up matching dejavu.
Created attachment 334804 [details] Patch
Created attachment 334805 [details] Patch Include binary diffs
Committed r229164: <https://trac.webkit.org/changeset/229164>
<rdar://problem/38056646>