In “Source/WebCore/platform/graphics/freetype/FontCacheFreeType.cpp” the is one instance where we are special-casing the “sans” font family name, which is NOT a CSS generic font family name, in the first line of the following function: static inline bool isCommonlyUsedGenericFamily(const String& familyNameString) { return equalLettersIgnoringASCIICase(familyNameString, "sans-serif"_s) || equalLettersIgnoringASCIICase(familyNameString, "serif"_s) || equalLettersIgnoringASCIICase(familyNameString, "monospace"_s) || equalLettersIgnoringASCIICase(familyNameString, "fantasy"_s) #if PLATFORM(GTK) || equalLettersIgnoringASCIICase(familyNameString, "-webkit-system-font"_s) || equalLettersIgnoringASCIICase(familyNameString, "-webkit-system-ui"_s) #endif || equalLettersIgnoringASCIICase(familyNameString, "cursive"_s); } Matching the “sans” name here skips a part of the CSS font fallback algorithm, which results in websites which use e.g. “font-family: sans” to end up picking an apparently semi-random choice of font depending on how FontConfig is configured. Given that a number of Linux distributions include font packages which have drop-in FontConfig configuration files which may define replacements and/or aliases for a family named “sans”, each user may see a slightly different outcome due to this bug. The solution is to do like the rest of the WebKit font implementations and not handle “sans” as a generic family name -- because it is not.
Created attachment 468705 [details] Screenshot of two browser, one of them with the “sans” matching removed Here's a screenshot comparing how WebKitGTK behaves today (left), and with the match for “sans” removed (right). The odd choice on the left was because this particular system does not have a FontConfig “sans” alias in the configuration, and FontConfig ends up picking a symbols font (Font Awesome), which has these oddball latin characters.
(In reply to Adrian Perez from comment #1) > Created attachment 468705 [details] > Screenshot of two browser, one of them with the “sans” matching removed > > Here's a screenshot comparing how WebKitGTK behaves today (left), and > with the match for “sans” removed (right). The odd choice on the left > was because this particular system does not have a FontConfig “sans” > alias in the configuration, and FontConfig ends up picking a symbols > font (Font Awesome), which has these oddball latin characters. Of course if I make sure that there is a “sans” alias defined in the FontConfig configuration, that ends up being picked. I think in case somebody has an oddball configuration like the one I used for testing, having a serif font picked as fallback is still better than picking a symbols font.
Pull request: https://github.com/WebKit/WebKit/pull/20776
Committed 271007@main (9479bf3bdea7): <https://commits.webkit.org/271007@main> Reviewed commits have been landed. Closing PR #20776 and removing active labels.
<rdar://problem/118680927>