Would "font-display: block;" do the trick?

Maybe? I am unsure how does our test runner decides to take a screenshot.

And if it does work, can we run with font-display:block on all our tests?

@dpranke, do you know who knows?

I did know at one point where (and when) we snapshot the page, but it's probably more useful for someone currently working on blink to look into this; I know we've changed at least some of the font-loading logic for some of this recently.

If you are curious about what these flakes look like, check out "Flaky" at

https://storage.googleapis.com/chromium-layout-test-archives/win7_chromium_rel_ng/58510/layout-test-results/results.html

row-progression-vlr-005.xht nicely illustrates the issue.

The root cause is the infamous long-standing issue  https://crbug.com/507054 

The current situation is that the screenshot happens right after the document is loaded, but webfont loading does not block document.onload in Chromium. The interaction here seems also unclear in the spec. Upstream WPT currently uses a hacky workaround by injecting JS to tests to wait for both document.onload, document.fonts.ready, and a forced repaint via rAF. ("font-display: block" might work as well.)

It's got a very long history, and many people have tried to fix the issue. I'm the current assignee, but haven't found any breakthrough in the limited time this quarter (my attempt of injecting JS failed for unknown reasons). I'll try again in Q1.

There are a lot of tests using webfonts showing different levels of flakiness. It's probably not practical to "fix" the tests themselves (I'd argue it's a bug of the test runner). Perhaps, we can mark the worst offenders as flaky for now?

I'd also appreciate anyone interested in this issue and willing to help me / work together to fix it for good.

Thanks for the update robertma. I agree that fixing the tests isn't practical. Perhaps we could add font-display block to the default user agent style sheet for content_shell?