Filed by: archaeopteryx [at] coole-files.de https://treeherder.mozilla.org/logviewer.html#?job_id=116647951&repo=mozilla-inbound https://queue.taskcluster.net/v1/task/D6bOTs_3RkqH6Dv9DDSOfQ/runs/0/artifacts/public/logs/live_backing.log https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/D6bOTs_3RkqH6Dv9DDSOfQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

the failures here are on non debug (opt + pgo), here is a reftest analyzer: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/K1YoT7pGQg2GYeDczk1Reg/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1 it looks like the fonts are different. :milan, I see you are the triage owner for this test case, can you help prioritize this and get this resolved when appropriate?

Jonathan, is this something we can avoid?

ISTM that we currently have a widespread problem with reftests erratically failing to load a font (quickly enough?) and rendering with a fallback. I don't know whether this represents a real failure in font loading, or a failure in restyling when the font becomes available and should then be applied to the element that requested it. So I believe this is just one of a huge number of intermittent-failure bugs that have been filed in recent weeks (or is it months now?) and all represent the same underlying unreliability, which can end up hitting almost any reftest, especially those that load webfont resources. But there have been some strange examples that didn't involve webfonts, too, so I'm not convinced this is really a webfont failure at all; I have a suspicion it might be a restyling or reflow bug, and just happens to show up frequently in tests that use webfonts because that's one scenario where we find ourselves doing an extra reflow after the initial reflow triggers font loading, and then font loading completes and triggers reflow. It seems to affect (primarily? almost exclusively?) Win7 tests, perhaps because that tends to be slower than our other desktop platforms? I don't really have any idea how to debug this, as I don't know how to reproduce it locally (and the failures seem much too sporadic to reliably identify a regression range where it started). It makes me very sad.

See bug 1391515 for an example of a similar-looking failure (i.e. failure to instantiate/use the correct font for an element in the testcase) that does not involve a webfont, it's just using installed platform fonts. And even more weird and wonderful, bug 1392106 where just a certain glyph fails to render. It all smells to me rather like we're hitting intermittent failures such as a shortage of resources (memory?) somewhere in the Windows graphics system, leading to a font that fails in some way.

:jfkthame, is there a tracking bug for all these windows 7 specific font issues?

Bug 1396260 was filed as a higher-level bug about the underlying cause of these widespread, highly-intermittent failures (though I'm not totally convinced it's specific to webfonts, as that bug suggests; I think it may be a wider issue yet). In the absence of anything clearer, though, I guess we could mark them all as dependent on that.

we run reftests in 32 chunks now