I am encountering a problem that could be the same bug, with custom fonts sometimes not loading in a WKWebView
It appears that in some cases, if a custom @font-face is declared but not actually used until after DOM load is finished -- i.e. it is only used in content added via javascript -- the font file is not actually fetched.
So, given this CSS:
@font-face {
		font-family: 'Foobar';
		src: url('fonts/some-font.woff2') format('woff2');
		font-weight: 400;
		font-style: normal;
}
And given this HTML, inserted into the DOM after load via script:
<span style="font: 400 20px Foobar">text</span>
The result is -- sometimes -- the font is not rendered with the correct font face.
The behaviour is consistent by content, meaning we have two complex pages which use the same font-face in very similar content loaded by the same script -- on one page, it will load correctly, consistently -- on the other page it will fail to load, consistently.
Notes I can tell from a Safari debugger connected to the webview in simulator:
There is no attempt made to fetch the font file. Networking tab does not show it at all
The font rendering engine appears to be working as expected, for example after a delay of about 2 seconds it will fallback to another font and then display the text. If I add CSS "font-display: swap;" it will show the fallback font immediately.
In other words, the renderer behaves as if the font file HTTP fetch timed out waiting for a response; except that no actual attempt to fetch the file was actually made.
Of note, not all such loads are failing. We have some content where it works (consistently) and other content where it does not work (consistently), for no apparent reason. Which leads me to guess is some sort of timing issue -- if the font system asks for a font download at just the wrong time, it doesn't work.
Unfortunately I don't have a clear example to provide -- we don't maintain the app, we only provide content which is loaded into the WKWebView -- and it's very complicated content.
kypatterson
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
From
Canada
Post
Replies
Boosts
Views
Activity
Oh, one more thing -- I discovered a work-around. If I preload the font file, it works, i.e. if I add this to <head> in the html:
<link rel="preload" as="font" href="fonts/some-font.woff2">
Then everything works as expected.
Sorry to keep posting but I'm finding more info as I test.
The problem can also occur with content that is in the initial DOM, if that content is not displayed until later on (due to script changing style/class). So the issue likely has nothing to do with initial DOM state, it has to do with whether the font face is utilized immediately or not until later.