[webkit-changes] [WebKit/WebKit] 3f1cb9: REGRESSION (260781 at main): [iOS] TestWebKitAPI.Font...

[Myles C. Maxfield]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3f1cb9750c4d8b376bcb35de57729f53af0ff833
      https://github.com/WebKit/WebKit/commit/3f1cb9750c4d8b376bcb35de57729f53af0ff833
  Author: Myles C. Maxfield <mmaxfield at apple.com>
  Date:   2023-02-27 (Mon, 27 Feb 2023)

  Changed paths:
    M Source/WebCore/editing/cocoa/FontAttributeChangesCocoa.mm
    M Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp
    M Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.h

  Log Message:
  -----------
  REGRESSION (260781 at main): [iOS] TestWebKitAPI.FontAttributes.FontTextStyle is consistently failing
https://bugs.webkit.org/show_bug.cgi?id=252916
rdar://105891055

Reviewed by Wenson Hsieh.

This was caused by the logic in FontChanges::platformFontFamilyNameForCSS(). When a font
change occurs, the FontChanges object represents it with 2 fields: m_fontName and m_fontFamily.
The purpose of FontChanges::platformFontFamilyNameForCSS() is to determine what value should be
supplied to the font-family CSS property, to represent the change.

The logic in that function is: Prefer using m_fontFamily, but only if round-tripping the font
family through our font selection logic would end up creating the same font that's specified by
m_fontName. In the previous sentence, the phrase "the same font" is implemented by comparing
PostScript name. If round-tripping the font creates a different font than m_fontName, use
m_fontName directly.

However, when the font changes to a text style font, m_fontName is ".SFUI-Regular" and
m_fontFamily is "UICTFontTextStyleTitle1". FontChanges::platformFontFamilyNameForCSS() was
finding that round-tripping the family through our font selection code was no longer producing
a font with the exact same postscript name as ".SFUI-Regular", and was therefore implementing
the font change by specifying "font-family: .SFUI-Regular" instead of
"font-family: UICTFontTextStyleTitle1". Ever since 240717 at main, dot-prefixed fonts intentionally
don't work in WebKit, so "font-family: .SFUI-Regular" was causing the test to fail.

Our round-tripping code wasn't producing a font with the exact same name as ".SFUI-Regular"
because it was instead producing a font with the name ".SFUI-Regular_wdth_opsz_GRAD_wght1F40000".
This font name _means_ the same thing as the original, but it's a synthesized name that Core Text
created. Eventually, we should migrate this check to be more robust.

However, a more straightforward solution is to just react to the fact that dot-prefixed fonts
intentionally don't work in WebKit, and therefore FontChanges::platformFontFamilyNameForCSS()
should just not return a dot-prefixed font name. This is more defensive than changing the font
equality check, and it's also easier to implement. If there are behavior changes in content,
those behavior changes would be to make more fonts work as requested.

* Source/WebCore/editing/cocoa/FontAttributeChangesCocoa.mm:
(WebCore::FontChanges::platformFontFamilyNameForCSS const):
* Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp:
(WebCore::fontNameIsSystemFont):
* Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.h:

Canonical link: https://commits.webkit.org/260866@main