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.ro...@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@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 <ph...@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@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 <mago...@igalia.com>
  Date:   2025-02-05 (Wed, 05 Feb 2025)

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

  Log Message:
  -----------
  Cherry-pick 289775@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
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to