Intermittent reftest failures due to font selection choices

[jdm]

Test:

Reference:

https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/CSS2/syntax/at-charset-001.xht
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/CSS2/syntax/at-charset-001-ref.xht
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/CSS2/syntax/support/at-charset-001.css

It's not clear to me how this can happen, but it does.

[jdm]

[jdm]

This is a relatively common intermittent failure on taskcluster mac jobs; this will only get worse as we add more of them.

[jdm]

The info added to #23375 has yielded interesting output like the following:

"[2019-05-14T23:50:05Z INFO  gfx::font] couldn't find font for 'T' (54) in families [FontGroupFamily { font_descriptor: FontDescriptor { template_descriptor: FontTemplateDescriptor { weight: FontWeight(400.0), stretch: FontStretch(NonNegative(Percentage(1.0))), style: Normal }, variant: Normal, pt_size: 16px }, family_descriptor: FontFamilyDescriptor { name: Generic(Atom('serif' type=static)), scope: Any }, loaded: true, font: None }]"

I find this highly suspect!

[jdm]

I have a theory that this occurs when the macos font backend's FontHandle::new_from_template is called with a None pt_size argument. This chooses 0.0 for a point size, then FontTemplateData::ctfont instantiates the font with a point size of 0.1, but all queries for the font use 0.0 and won't find it. This could explain why the fallback behaviour is triggered.

[jdm]

This can happen if FontTemplate::instantiate is called, rather than FontContext::create_font, which happens in FontContext::descriptor.

[jdm]

Theory busted - we store the unclamped point size in the hashmap, not the clamped one :(