FontCascadeFonts::primaryFont() specifically hardcodes the first FontRange inside the FontCascade ("realizeFallbackRangesAt(description, 0)"), which could be loading. If it's in the middle of loading, this will result in the interstitial font (Times). All the other codepaths which call realizeFallbackRangesAt() will detect that it returned the interstitial font and keep iterating through the font-family list, but this codepath doesn't. This means that the metrics for the primary font (which is used for things like line-height) may disagree with all the rendered characters. This is particularly problematic if the loading font transitions to the failed state, which is how font-display:fallback is implemented. If this situation, realizeNextFallback() will keep iterating past the failed font-family item, which means that the primary font will change. This can change things like line-height, and therefore cause a visual flash (which is contrary to the whole reason font-display:fallback exists in the first place).
One solution would be to add a loop inside FontCascadeFonts::primaryFont() to skip over interstitial fonts (the same way all the other callers of realizeFallbackRangesAt() work). Another solution would be to add a new state to CSSFontFace which wouldn't be treated like failure. Both of these solutions are pretty scary changes.
Created attachment 330669 [details] Repro (needs external font file and slow server) Repro attached. Requires an external font file and a slow (longer than 3 seconds) server when serving the font file.
The repro shows how the text moves because the line height changes after 3 seconds because the font-face block gets marked as failed.
Created attachment 330670 [details] Python Server
Created attachment 330770 [details] Patch
Created attachment 330776 [details] Patch
Comment on attachment 330776 [details] Patch Clearing flags on attachment: 330776 Committed r226668: <https://trac.webkit.org/changeset/226668>
All reviewed patches have been landed. Closing bug.
<rdar://problem/36390845>