Permanent failure in /css21_dev/html4/font-family-013.htm and /css21_dev/html4/fonts-013.htm

[jdm]

These tests are both using unicode characters, and the run which contained a failure showed the characters appearing as boxes.

The test itself is interesting:

   .a span.test { font: 4em "Ahem", "Times New Roman"; }
   .a span.control { font: 4em "Times New Roman"; }
   .b span.test { font: 4em "Ahem", "Arial"; }
   .b span.control { font: 4em "Arial"; }
   .c span.test { font: 4em "Ahem", "Courier New"; }
   .c span.control { font: 4em "Courier New"; }

It looks like it's assuming that Ahem should not be present??

[jdm]

It's unclear to me why this would intermittently fail unless we haven't made Ahem available on all machines.

[jdm]

Or maybe this is testing glyph fallback behaviour, since presumably Ahem doesn't include those characters...

[jdm]

Oh, are we missing the msttcore fonts on some linux machines? @larsbergstrom @metajack @edunham

[jdm]

This was first seen on linux2, by by the way.

[jdm]

11:17 <jdm> jack: actually wait, my theory doesn't hold up because the output is <box><box><box><box> - test
11:17 <jdm> jack: with the ones on the left being "Ahem", [something else], and the ones on the right being [something else]
11:18 <jdm> so if the font was missing we should see <box><box><box><box>
11:18 <jdm> on both sides
11:18 <jack> ah
11:18 <jdm> so perhaps this is an actual problem in our glyph selection code or something

[jdm]

Seen on linux1, too. Did we make a change to saltfs and not actually update it until I did so earlier today?

[metajack]

So I added msttcorefonts to our salt configs a week or so ago. I tested it a few times and it seemed ok, but perhaps that is busted somehow.

See servo/saltfs#111 and servo/saltfs#112

[metajack]

@bors-servo retry

• spinning up builders to test possible fix

[SimonSapin]

These tests assume that Ahem is installed, but rely on the next family in font-family being selected when Ahem has no glyph for a given character. For a while they passed because Ahem was not available. #7013 added Ahem, and these tests started failing because the fallback did not occur correctly. They started passing again when we installed msttcorefonts on the builders at some point.

If they fail again now, the most likely explanation is that msttcorefonts is missing.

[metajack]

They are missing. The build automation is failing to install these correctly, and I'm still debugging.

[metajack]

This is now fixed.

[jdm]

This started happening again.

[Ms2ger]

I manually installed the fonts on linux2.

[SimonSapin]

I think that #8053 is a better long-term solution.

[gsnedders]

Even without the MS fonts installed shouldn't they still pass?

The final stage of font matching algorithm is:

If there is no font within the family selected in 2, then use a UA-dependent default 'font-family' and repeat step 2, using the best match that can be obtained within the default font. If a particular character cannot be displayed using this font, then the UA may use other means to determine a suitable font for that character. The UA should map each character for which it has no suitable font to a visible symbol chosen by the UA, preferably a "missing character" glyph from one of the font faces available to the UA.

That means the essentially the test becomes equivalent to:

<p>The two must look the same:</p>
<p style="font-family: Ahem, Times">Ţęşţ</p>
<p style="font-family: initial">Ţęşţ</p>

Both should render using the UA default 'font-family', no?

[SimonSapin]

Yes, it sounds like we have a bug in font selection/fallback and installing MS fonts just avoids triggering it. Long term, we should investigate that bug and fix it. In the mean time, installing MS fonts on CI servers is troublesome so maybe we can simply disable these tests.

[larsbergstrom]

@metajack This is happening again after the move to the new EC2 builders. I think we worked around it before by having people just log in and install the fonts manually. Should we do that again, or disable the tests?

[larsbergstrom]

Hrm, it says installed on both machines:

root@ip-172-31-37-44:~# sudo apt-get install msttcorefonts
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'ttf-mscorefonts-installer' instead of 'msttcorefonts'
ttf-mscorefonts-installer is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 86 not upgraded.
root@ip-172-31-37-44:~# 

[larsbergstrom]

Also, are we sure we can't use the fonts-liberation package instead to avoid this, at least for CI/testing purposes?

[larsbergstrom]

You can try to force a re-install to see if the eula was accidentally not accepted or not completed by doing:

sudo apt-get --purge --reinstall install ttf-mscorefonts-installer

I suspect what's happening with the rules is sometimes the eula is not agreed to, and then the package is marked as installed without having actually installed any files.

[SimonSapin]

I’m in favor of disabling these tests until we fix the underlying font selector issues so that Microsoft fonts are not required.

[frewsxcv]

This is happening again

#9214 (comment)

#9209 (comment)

[edunham]

@larsbergstrom Manually reinstalling the font on a running buildslave will squash this issue for an indeterminate period of time -- unless we save the changes to a new AMI then configure Buildbot to use it, we'll hit a regression every time the slave gets terminated then restarted from the old (broken) AMI.

Is there a reason we can't perform this test successfully with free fonts? If so, we can make a new AMI with the fonts installed and EULA accepted and tell Buildbot to use it instead, though copying in that way may not even technically be permitted by the fonts' licenses.

[SimonSapin]

I’m in favor of disabling these tests until we fix the underlying font selector issues so that Microsoft fonts are not required.

#9235

[metajack]

@edunham I don't understand why we can't make the automation work when the manual interaction does work. I really don't want to be using custom AMIs, since that makes everything more difficult, and harder for community members to reproduce easily.

[jdm]

This shouldn't affect us any longer.