[webkit-changes] [WebKit/WebKit] e43b88: Cherry-pick 264114 at main (5dd594fd96bb). https://bu...

Simon Fraser noreply at github.com
Sat May 20 05:16:06 PDT 2023


  Branch: refs/heads/webkitglib/2.40
  Home:   https://github.com/WebKit/WebKit
  Commit: e43b88b16637965818e85a107c6edb00ad8348d1
      https://github.com/WebKit/WebKit/commit/e43b88b16637965818e85a107c6edb00ad8348d1
  Author: Michael Catanzaro <mcatanzaro at redhat.com>
  Date:   2023-05-20 (Sat, 20 May 2023)

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

  Log Message:
  -----------
  Cherry-pick 264114 at main (5dd594fd96bb). https://bugs.webkit.org/show_bug.cgi?id=256470

    Crash in PDFDocument::sendPDFArrayBuffer
    https://bugs.webkit.org/show_bug.cgi?id=256470

    Reviewed by Tim Nguyen.

    When page loading is stopped, PDFDocument::finishedParsing will be
    called (which makes sense, because the parsing is finished, even if not
    completed). Here sendPDFArrayBuffer will be called if the content script
    has been loaded, even if there is no main resource data yet. We need
    guards to ensure we don't dereference nullptr when there is no main
    resource data.

    Additionally, I've added an extra guard to ensure the document loader is
    not nullptr. Maybe that's not possible here -- not sure -- but since the
    function returns a pointer and not a reference it seems safer to check.

    * Source/WebCore/html/PDFDocument.cpp:
    (WebCore::PDFDocument::sendPDFArrayBuffer):

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


  Commit: 0d947d1cfcaf5a0361a0d3f4ce27306066024224
      https://github.com/WebKit/WebKit/commit/0d947d1cfcaf5a0361a0d3f4ce27306066024224
  Author: Joseph Griego <jgriego at igalia.com>
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
    M Source/WTF/wtf/text/StringCommon.h
    M Tools/TestWebKitAPI/Tests/WTF/StringCommon.cpp

  Log Message:
  -----------
  Cherry-pick 264088 at main (d565c2070f7a). https://bugs.webkit.org/show_bug.cgi?id=256606

    Fix off-by-one in WTF::findIgnoringASCIICaseWithoutLength
    https://bugs.webkit.org/show_bug.cgi?id=256606

    Reviewed by Chris Dumez.

    A needle identical to the haystack won't be found by this function because of
    the length comparison used. Luckily, this function is unused except in testb3,
    so nothing else really needs to be changed.

    * Source/WTF/wtf/text/StringCommon.h:
    (WTF::findIgnoringASCIICaseWithoutLength):

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


  Commit: c1567e86b6b981448c1aab638cecc44f12a2662c
      https://github.com/WebKit/WebKit/commit/c1567e86b6b981448c1aab638cecc44f12a2662c
  Author: Simon Fraser <simon.fraser at apple.com>
  Date:   2023-05-20 (Sat, 20 May 2023)

  Changed paths:
    A LayoutTests/fast/css/background-clip-text-hairline-expected.html
    A LayoutTests/fast/css/background-clip-text-hairline.html
    M Source/WebCore/rendering/BackgroundPainter.cpp

  Log Message:
  -----------
  Cherry-pick 263526 at main (ccbeb1e341f1). https://bugs.webkit.org/show_bug.cgi?id=179333

    Hairline pixel crack around background-clip: text
    https://bugs.webkit.org/show_bug.cgi?id=179333
    rdar://54325642

    Reviewed by Alan Baradlay.

    When there is some non-integral transform (or a non axis-aligned transform) in the CTM, we could
    show some antialiasing noise at the edge of `background-clip: text` regions. This noise was not
    in the buffer used as a mask, but seemed to come from some the transparency layer operations.

    We can work around it by inflating maskRect by a pixel on each size, which pads the intermediate
    buffer, and the size of the transparency layer.

    * LayoutTests/fast/css/background-clip-text-hairline-expected.html: Added.
    * LayoutTests/fast/css/background-clip-text-hairline.html: Added.
    * Source/WebCore/rendering/BackgroundPainter.cpp:
    (WebCore::BackgroundPainter::paintFillLayer):

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


Compare: https://github.com/WebKit/WebKit/compare/448a40e3dd2e...c1567e86b6b9


More information about the webkit-changes mailing list