[webkit-changes] [WebKit/WebKit] 9f5ff4: Cherry-pick 289653 at main (1974b406003a). https://bu...

[Miguel Gómez]

  Branch: refs/heads/webkitglib/2.46
  Home:   https://github.com/WebKit/WebKit
  Commit: 9f5ff4143c4eab6f34111b82882d745f0e2aa2d3
      https://github.com/WebKit/WebKit/commit/9f5ff4143c4eab6f34111b82882d745f0e2aa2d3
  Author: Vitor Roriz <vitor.roriz at apple.com>
  Date:   2025-02-03 (Mon, 03 Feb 2025)

  Changed paths:
    A LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/matching/font-unicode-presented-as-emoji-outline-expected.html
    A LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/matching/font-unicode-presented-as-emoji-outline-ref.html
    A LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/matching/font-unicode-presented-as-emoji-outline.html
    A LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/matching/resources/AhemCrossmarkSupport.otf
    M Source/WebCore/platform/graphics/FontCascadeFonts.cpp

  Log Message:
  -----------
  Cherry-pick 289653 at main (1974b406003a). https://bugs.webkit.org/show_bug.cgi?id=286749

    webengineshackfest.org: 'close' button does not show 'emoji' inside on WebKit / Safari
    rdar://128019815
    https://bugs.webkit.org/show_bug.cgi?id=286749

    Reviewed by Sammy Gill.

    At commit [1] we improved the rendering of glyphs that should be presented as emoji
    according to unicode. This commit makes sure that if we find a font that support
    a given "emoji presented" codepoint but this font can't render the emoji in a colorful way,
    we will continuing falling back.

    The problem is that if the author specifies a font that can represent the codepoint
    but as a outline, we will refuse to render that codepoint with such a font, which is
    the bug here reported.

    Here we are proposing to honor the solution of [1] only if a generic font family is specified.
    That way, if author specifies something like `font-family: system-ui` we will try to find the
    best system font we can with colorful glyphs. Otherwise, if author specifies a non-generic font
    that can support the codepoint we will use this font.

    [1]: https://commits.webkit.org/266089@main

    * LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/matching/font-unicode-presented-as-emoji-outline-expected.html: Added.
    * LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/matching/font-unicode-presented-as-emoji-outline-ref.html: Added.
    * LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/matching/font-unicode-presented-as-emoji-outline.html: Added.
    * LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/matching/resources/AhemCrossmarkSupport.otf: Added.
    * Source/WebCore/platform/graphics/FontCascadeFonts.cpp:
    (WebCore::FontCascadeFonts::glyphDataForVariant):

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

Canonical link: https://commits.webkit.org/282416.447@webkitglib/2.46


  Commit: 11cdb86c25e48cf69027ba7469c63da4c7652002
      https://github.com/WebKit/WebKit/commit/11cdb86c25e48cf69027ba7469c63da4c7652002
  Author: Philippe Normand <philn at igalia.com>
  Date:   2025-02-03 (Mon, 03 Feb 2025)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp

  Log Message:
  -----------
  Cherry-pick 289444 at main (ace5a3241a15). https://bugs.webkit.org/show_bug.cgi?id=286577

    [GStreamer] Fix incorrect usage of StringView::rawCharacters()
    https://bugs.webkit.org/show_bug.cgi?id=286577

    Reviewed by Darin Adler.

    Our use of StringView::rawCharacters() is incorrect, so instead, convert the StringView to a CString.

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

Canonical link: https://commits.webkit.org/282416.448@webkitglib/2.46


  Commit: 4f017747e6e56408f1f20648033ea757645b97b1
      https://github.com/WebKit/WebKit/commit/4f017747e6e56408f1f20648033ea757645b97b1
  Author: Miguel Gomez <magomez at igalia.com>
  Date:   2025-02-05 (Wed, 05 Feb 2025)

  Changed paths:
    M Source/WebCore/html/HTMLCanvasElement.cpp

  Log Message:
  -----------
  Cherry-pick 289775 at main (9b2ca446ce97). https://bugs.webkit.org/show_bug.cgi?id=286674

    [GTK][WPE] Crash loading https://webassembly.sh/ in CPU rendering mode
    https://bugs.webkit.org/show_bug.cgi?id=286674

    Reviewed by Carlos Garcia Campos.

    Fix the check to paint the contents on the canvas when its ImageBuffer hasn't
    been created yet: if we do need to paint the transparent black rectangle, do
    not call surfaceBufferToImageBuffer() because that will trigger the creation
    of the ImageBuffer, potentially changing the canvas into an accelerated one in
    the middle of the paint, which will cause a crash. Paint the transparent black
    rectangle using fillRect() instead.

    * Source/WebCore/html/HTMLCanvasElement.cpp:
    (WebCore::HTMLCanvasElement::paint):

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

Canonical link: https://commits.webkit.org/282416.449@webkitglib/2.46


Compare: https://github.com/WebKit/WebKit/compare/301fe230eb69...4f017747e6e5

To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications