tree a5ae86ee68831d818ab56f7a7ab31763a61a2bd9
parent fff5469af9e21121a01bc52b64d66a2e93b51665
author mmaxfield@apple.com <mmaxfield@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1570736535 +0000
committer mmaxfield@apple.com <mmaxfield@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1570736535 +0000

FontFaceSet's ready promise is not always resolved
https://bugs.webkit.org/show_bug.cgi?id=202548

Reviewed by Youenn Fablet.

Source/WebCore:

When we do layout on an element, FontRanges::glyphDataForCharacter() will cause the first
available font to start loading, but will continue looking at subsequent fonts to see if
there's a good one we can render while the load is happening. When looking for a fallback
font, it calls FontRanges::Range::font() with a ExternalResourceDownloadPolicy set to
Forbid. This is fine, except that a side effect of calling this function is that the
CSSFontFace marks itself as Loading, which means document.fonts.ready is deferred. Then,
the load finishes, and the subsequent CSSFontFace is never actually used, meaning it never
exits the Loading state, which means document.fonts.ready never fires.

The solution to this is to just only allow the font to enter the Loading state if it's not
one of these "subsequent" fonts.

Test: fast/text/fontfaceset-ready-not-fired.html

* css/CSSFontFace.cpp:
(WebCore::CSSFontFace::pump):

LayoutTests:

* fast/text/fontfaceset-ready-not-fired-expected.txt: Added.
* fast/text/fontfaceset-ready-not-fired.html: Added.
* fast/text/fontfaceset-ready-not-fired-2-expected.txt: Added.
* fast/text/fontfaceset-ready-not-fired-2.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@250983 268f45cc-cd09-0410-ab3c-d52691b4dbfc