Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3208096991b941e064c217b0a903a8374f2507a2
      
https://github.com/WebKit/WebKit/commit/3208096991b941e064c217b0a903a8374f2507a2
  Author: Darin Adler <[email protected]>
  Date:   2025-10-19 (Sun, 19 Oct 2025)

  Changed paths:
    M LayoutTests/fast/text/font-face-family-expected.txt
    M LayoutTests/fast/text/font-face-family.html
    M Source/WebCore/css/CSSFontFace.cpp
    M Source/WebCore/css/FontFace.cpp
    M Source/WebCore/css/FontFace.h
    M Source/WebCore/css/FontFace.idl
    M Source/WebCore/css/parser/CSSPropertyParserConsumer+Font.cpp
    M Source/WebCore/css/parser/CSSPropertyParserConsumer+Font.h

  Log Message:
  -----------
  REGRESSION (Safari 26): `@font-face` / `FontFace.family` fails when font 
family name contains space (e.g. "Lato 2")
https://bugs.webkit.org/show_bug.cgi?id=300620
rdar://162637501

Reviewed by Tim Nguyen.

While the specification isn't clear enough on this, the FontFace interface 
should
treat the font family as just a string, without parsing or serializing steps.
This is the de facto standard since both Chrome and Firefox work this way, and
WebKit worked roughly this way before changes earlier this year.

Besides this bug fix it would be good to:
- make the specification correct and unambiguous on this point
- add tests to Web Platform Tests
- add tests covering FontFace family setter
- add tests covering FontFace with family from @font-face rule

* LayoutTests/fast/text/font-face-family-expected.txt: Updated to expect font
family name to be treated as a string, not parsed with the <font-family> syntax.
* LayoutTests/fast/text/font-face-family.html: Ditto.

* Source/WebCore/css/CSSFontFace.cpp:
(WebCore::CSSFontFace::family const): Get the string value of the font family
property rather than serializing it. Code is slightly confusing because of the
way we share the StyleProperties between the font-family descriptor and the
font-family property, since the latter can contain a list of families, and
can include generic families rather than families specified by font name.

* Source/WebCore/css/FontFace.cpp:
(WebCore::FontFace::create): Updated since setFamily no longer requires a
ScriptExecutionContext argument since it no longer does any parsing.
(WebCore::FontFace::setFamily): Set from a string, without parsing.
Retains the "empty string is a syntax error" behavior, since we have a
test that expects it; would be easy to remove that too and allow empty
strings, but I'd want to test the other browser engine behavior first,
and it's not urgent to deal with this edge case.
* Source/WebCore/css/FontFace.h: Removed the ScriptExecutionContext from
the setFamily function, since it no longer does parsing.
* Source/WebCore/css/FontFace.idl: Ditto.

* Source/WebCore/css/parser/CSSPropertyParserConsumer+Font.cpp:
(WebCore::CSSPropertyParserHelpers::parseFontFaceFontFamily): Deleted.

* Source/WebCore/css/parser/CSSPropertyParserConsumer+Font.h: Deleted
unneeded parseFontFaceFontFamily function declaration.

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to