[webkit-changes] [WebKit/WebKit] 899e78: Cherry-pick 280817 at main (88b600d040a8). https://bu...

Adrian Perez noreply at github.com
Fri Sep 6 05:30:41 PDT 2024


  Branch: refs/heads/webkitglib/2.44
  Home:   https://github.com/WebKit/WebKit
  Commit: 899e78f18c3f48f113a5cc85cc50e04ddd5154ec
      https://github.com/WebKit/WebKit/commit/899e78f18c3f48f113a5cc85cc50e04ddd5154ec
  Author: Richard Robinson <richard_robinson2 at apple.com>
  Date:   2024-09-05 (Thu, 05 Sep 2024)

  Changed paths:
    M Source/WebKit/Shared/EditingRange.cpp

  Log Message:
  -----------
  Cherry-pick 280817 at main (88b600d040a8). https://bugs.webkit.org/show_bug.cgi?id=276403

    Debug assertion `ASSERT(editingRange.location != notFound)` is frequently hit in Mail compose
    https://bugs.webkit.org/show_bug.cgi?id=276403
    rdar://131427649

    Reviewed by Ryosuke Niwa.

    The pattern of clients calling `selectedRangeWithCompletionHandler`, then passing the resulting range
    to `attributedSubstringForProposedRange` is not uncommon and happens in several circumstances (for example,
    AppKit does this when replying to an email in Mail, and WritingTools does this when showing the affordance).

    Since it is perfectly valid for `selectedRangeWithCompletionHandler` to return `NSNotFound`, and also valid
    for `attributedSubstringForProposedRange` to receive `NSNotFound`, and also results in valid behavior (when
    it is notFound, the behavior is just to return the whole range of the editable content), this assertion can
    and should be removed.

    * Source/WebKit/Shared/EditingRange.cpp:
    (WebKit::EditingRange::toRange):

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

Canonical link: https://commits.webkit.org/274313.417@webkitglib/2.44


  Commit: 090445c6af80bf9782f46e0cc1f380a0dc0d0d97
      https://github.com/WebKit/WebKit/commit/090445c6af80bf9782f46e0cc1f380a0dc0d0d97
  Author: Ryan Reno <rreno at apple.com>
  Date:   2024-09-05 (Thu, 05 Sep 2024)

  Changed paths:
    A LayoutTests/fast/reporting/reporting-observer-callback-does-not-leak-expected.txt
    A LayoutTests/fast/reporting/reporting-observer-callback-does-not-leak.html
    A LayoutTests/fast/reporting/resources/reporting-observer-with-callback.html
    M Source/WebCore/Modules/reporting/ReportingObserver.cpp
    M Source/WebCore/Modules/reporting/ReportingObserver.h
    M Source/WebCore/Modules/reporting/ReportingObserver.idl
    M Source/WebCore/Modules/reporting/ReportingObserverCallback.h
    M Source/WebCore/Modules/reporting/ReportingObserverCallback.idl
    M Source/WebCore/Sources.txt
    M Source/WebCore/WebCore.xcodeproj/project.pbxproj
    A Source/WebCore/bindings/js/JSReportingObserverCustom.cpp

  Log Message:
  -----------
  Cherry-pick 280557 at main (33c1f1877fa2). https://bugs.webkit.org/show_bug.cgi?id=276080

    ReportingObserverCallbacks can leak the Document object
    https://bugs.webkit.org/show_bug.cgi?id=276080
    rdar://130908426

    Reviewed by Ryosuke Niwa.

    By default callbacks are held as JSC::Strong handles. This creates a GC
    Root which will keep anything captured in the callback function alive.
    On sites like britannica.com, many documents are captured in this way
    and lead to memory leaks.

    This patch makes ReportingObserverCallback Weak and keeps the callback
    wrapper alive via ReportingObserver's visitAdditionalChildren.

    * LayoutTests/fast/reporting/reporting-observer-callback-does-not-leak-expected.txt: Added.
    * LayoutTests/fast/reporting/reporting-observer-callback-does-not-leak.html: Added.
    * LayoutTests/fast/reporting/resources/reporting-observer-with-callback.html: Added.
    * Source/WebCore/Modules/reporting/ReportingObserver.cpp:
    (WebCore::ReportingObserver::callbackConcurrently):
    * Source/WebCore/Modules/reporting/ReportingObserver.h:
    * Source/WebCore/Modules/reporting/ReportingObserver.idl:
    * Source/WebCore/Modules/reporting/ReportingObserverCallback.h:
    * Source/WebCore/Modules/reporting/ReportingObserverCallback.idl:
    * Source/WebCore/Sources.txt:
    * Source/WebCore/WebCore.xcodeproj/project.pbxproj:
    * Source/WebCore/bindings/js/JSReportingObserverCustom.cpp: Added.
    (WebCore::JSReportingObserver::visitAdditionalChildren):

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

Canonical link: https://commits.webkit.org/274313.418@webkitglib/2.44


  Commit: 3e3287046a6979a3dfb55af11e4802aca2936722
      https://github.com/WebKit/WebKit/commit/3e3287046a6979a3dfb55af11e4802aca2936722
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-09-05 (Thu, 05 Sep 2024)

  Changed paths:
    M Source/WebKit/UIProcess/WebBackForwardCache.cpp
    M Source/WebKit/UIProcess/WebBackForwardCache.h

  Log Message:
  -----------
  Cherry-pick 280264 at main (e127c6bb3b51). https://bugs.webkit.org/show_bug.cgi?id=275744

    Make WebBackForwardCache's m_itemsWithCachedPage more robust
    https://bugs.webkit.org/show_bug.cgi?id=275744
    rdar://129706255

    Reviewed by Alex Christensen.

    Use a WeakListHashSet instead of a Vector<WeakPtr<>> for m_itemsWithCachedPage.
    This is less error-prone as it will avoid crashes if a WebBackForwardList item
    gets destroyed without unregistering itself from the WebBackForwardListCache
    first.

    This should avoid crashes such as in rdar://129706255.

    * Source/WebKit/UIProcess/WebBackForwardCache.cpp:
    (WebKit::WebBackForwardCache::addEntry):
    (WebKit::WebBackForwardCache::removeEntry):
    (WebKit::WebBackForwardCache::takeSuspendedPage):
    (WebKit::WebBackForwardCache::removeEntriesMatching):
    (WebKit::WebBackForwardCache::clear):
    * Source/WebKit/UIProcess/WebBackForwardCache.h:

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

Canonical link: https://commits.webkit.org/274313.419@webkitglib/2.44


  Commit: e4e39971b5d628e0164fac58fd65d75ce30e866a
      https://github.com/WebKit/WebKit/commit/e4e39971b5d628e0164fac58fd65d75ce30e866a
  Author: Jer Noble <jer.noble at apple.com>
  Date:   2024-09-05 (Thu, 05 Sep 2024)

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

  Log Message:
  -----------
  Cherry-pick 280251 at main (d8035e9cf316). https://bugs.webkit.org/show_bug.cgi?id=275718

    [Cocoa] CRASH in HTMLMediaElement::loadResource()
    https://bugs.webkit.org/show_bug.cgi?id=275718
    rdar://129570289

    Reviewed by Eric Carlson.

    From crashlogs, loadResource() is being called when m_player is null. This should not be possible,
    as the only site that clears m_player is clearMediaPlayer(), which cancels the task which calls
    loadResource().

    Null-check m_player, but leave an ASSERT_NOT_REACHED() in its place, to hopefully catch this state
    in debug builds and layout tests.

    * Source/WebCore/html/HTMLMediaElement.cpp:
    (WebCore::HTMLMediaElement::loadResource):

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

Canonical link: https://commits.webkit.org/274313.420@webkitglib/2.44


  Commit: 0d5e20b6b369bd13ddb1b854860cb80d6bff8cbc
      https://github.com/WebKit/WebKit/commit/0d5e20b6b369bd13ddb1b854860cb80d6bff8cbc
  Author: Said Abou-Hallawa <said at apple.com>
  Date:   2024-09-05 (Thu, 05 Sep 2024)

  Changed paths:
    A LayoutTests/fast/css/matrix-small-values-inverse-expected.txt
    A LayoutTests/fast/css/matrix-small-values-inverse.html
    M Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp

  Log Message:
  -----------
  Cherry-pick 279588 at main (1f6b653b2343). https://bugs.webkit.org/show_bug.cgi?id=274834

    DOMMatrix.inverse() returns NaN matrix for small but normal values
    https://bugs.webkit.org/show_bug.cgi?id=274834
    rdar://128960283

    Reviewed by Kimmo Kinnunen.

    Use std::isnormal(determinant) to check if DOMMatrix (or TransformationMatrix)
    isInvertible(). This will replace checking the determinant is less than a defined
    SMALL_NUMBER.

    * LayoutTests/fast/css/matrix-small-values-inverse-expected.txt: Added.
    * LayoutTests/fast/css/matrix-small-values-inverse.html: Added.
    * Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp:
    (WebCore::inverse):
    (WebCore::TransformationMatrix::isInvertible const):
    (WebCore::TransformationMatrix::inverse const):
    (WebCore::TransformationMatrix::isBackFaceVisible const):

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

Canonical link: https://commits.webkit.org/274313.421@webkitglib/2.44


  Commit: eafbd3ff06bea5de46c2bbdbd31e4b5679a812a9
      https://github.com/WebKit/WebKit/commit/eafbd3ff06bea5de46c2bbdbd31e4b5679a812a9
  Author: Mark Lam <mark.lam at apple.com>
  Date:   2024-09-05 (Thu, 05 Sep 2024)

  Changed paths:
    M Source/JavaScriptCore/bytecode/CodeBlock.cpp
    M Source/JavaScriptCore/bytecode/MetadataTable.cpp
    M Source/JavaScriptCore/bytecode/MetadataTable.h

  Log Message:
  -----------
  Cherry-pick 279300 at main (59012130505d). https://bugs.webkit.org/show_bug.cgi?id=274691

    Speculative mitigation against a crash involving CodeBlock::m_metadata.
    https://bugs.webkit.org/show_bug.cgi?id=274691
    rdar://127571559

    Reviewed by Yijia Huang and Yusuke Suzuki.

    We sometimes see crashes due to CodeBlock::m_metadata->unlinkedMetadata() being null.
    This change adds a speculative null check to mitigate against stepping on this.

    * Source/JavaScriptCore/bytecode/CodeBlock.cpp:
    (JSC::CodeBlock::~CodeBlock):
    * Source/JavaScriptCore/bytecode/MetadataTable.cpp:
    (JSC::MetadataTable::destroy):
    * Source/JavaScriptCore/bytecode/MetadataTable.h:
    (JSC::MetadataTable::isDestroyed const):

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

Canonical link: https://commits.webkit.org/274313.422@webkitglib/2.44


  Commit: 39549f9139aadb04e9e46c3cdd1e7319d425c48c
      https://github.com/WebKit/WebKit/commit/39549f9139aadb04e9e46c3cdd1e7319d425c48c
  Author: Said Abou-Hallawa <said at apple.com>
  Date:   2024-09-05 (Thu, 05 Sep 2024)

  Changed paths:
    A LayoutTests/fast/canvas/canvas-drawImage-negative-coordinate-expected.html
    A LayoutTests/fast/canvas/canvas-drawImage-negative-coordinate.html
    A LayoutTests/fast/canvas/canvas-drawImage-out-of-bounds-coordinate-expected.html
    A LayoutTests/fast/canvas/canvas-drawImage-out-of-bounds-coordinate.html
    M LayoutTests/imported/w3c/web-platform-tests/html/canvas/element/manual/drawing-images-to-the-canvas/drawimage_canvas-expected.txt
    M LayoutTests/imported/w3c/web-platform-tests/html/canvas/element/manual/drawing-images-to-the-canvas/drawimage_html_image-expected.txt
    R LayoutTests/platform/glib/imported/w3c/web-platform-tests/html/canvas/element/drawing-images-to-the-canvas/drawimage_canvas-expected.txt
    A LayoutTests/platform/glib/imported/w3c/web-platform-tests/html/canvas/element/manual/drawing-images-to-the-canvas/drawimage_canvas-expected.txt
    M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp

  Log Message:
  -----------
  Cherry-pick 278807 at main (5dd01bad437e). https://bugs.webkit.org/show_bug.cgi?id=202457

    Canvas drawImage should not alter the input source or the destination rectangles
    https://bugs.webkit.org/show_bug.cgi?id=202457
    rdar://127982607

    Reviewed by Kimmo Kinnunen.

    The input source rectangle was incorrectly clipped to the image source rectangle.
    The specs [1] means copying the pixels from the image should be limited to the
    image source rectangle. This clipped is already handled by the drawing SDK.

    The input source and the destination rectangles should not be altered because
    they are used to scale the image when it is drawn to the canvas.

    [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawimage

    * LayoutTests/fast/canvas/canvas-drawImage-negative-coordinate-expected.html: Added.
    * LayoutTests/fast/canvas/canvas-drawImage-negative-coordinate.html: Added.
    * LayoutTests/fast/canvas/canvas-drawImage-out-of-bounds-coordinate-expected.html: Added.
    * LayoutTests/fast/canvas/canvas-drawImage-out-of-bounds-coordinate.html: Added.
    * LayoutTests/imported/w3c/web-platform-tests/html/canvas/element/manual/drawing-images-to-the-canvas/drawimage_canvas-expected.txt:
    * LayoutTests/imported/w3c/web-platform-tests/html/canvas/element/manual/drawing-images-to-the-canvas/drawimage_html_image-expected.txt:
    * LayoutTests/platform/glib/imported/w3c/web-platform-tests/html/canvas/element/manual/drawing-images-to-the-canvas/drawimage_canvas-expected.txt: Renamed from LayoutTests/platform/glib/imported/w3c/web-platform-tests/html/canvas/element/drawing-images-to-the-canvas/drawimage_canvas-expected.txt.
    * Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:
    (WebCore::CanvasRenderingContext2DBase::drawImage):
    (WebCore::normalizeSourceAndDestination): Deleted.

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

Canonical link: https://commits.webkit.org/274313.423@webkitglib/2.44


  Commit: 264c56d26ba30bfa319cca0b58e681a33b36822f
      https://github.com/WebKit/WebKit/commit/264c56d26ba30bfa319cca0b58e681a33b36822f
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-09-05 (Thu, 05 Sep 2024)

  Changed paths:
    M Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.cpp

  Log Message:
  -----------
  Cherry-pick 278563 at main (d045dbe49089). https://bugs.webkit.org/show_bug.cgi?id=273918

    Add missing isolatedCopy() call in ServiceWorkerThreadProxy::fireMessageEvent()
    https://bugs.webkit.org/show_bug.cgi?id=273918

    Reviewed by Brady Eidson.

    ServiceWorkerThreadProxy::fireMessageEvent() is dispatching from the
    WebSWContextManagerConnection queue to the ServiceWorker thread, yet, it was
    failing to call isolatedCopy() on the ServiceWorkerOrClientData it is
    capturing.

    * Source/WebCore/workers/service/context/ServiceWorkerThreadProxy.cpp:
    (WebCore::ServiceWorkerThreadProxy::fireMessageEvent):

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

Canonical link: https://commits.webkit.org/274313.424@webkitglib/2.44


  Commit: aac758d4c6d849306b6df94737479136370e84bd
      https://github.com/WebKit/WebKit/commit/aac758d4c6d849306b6df94737479136370e84bd
  Author: Devin Rousso <hi at devinrousso.com>
  Date:   2024-09-05 (Thu, 05 Sep 2024)

  Changed paths:
    M Source/WebInspectorUI/UserInterface/Views/AnimationContentView.js

  Log Message:
  -----------
  Cherry-pick 280058 at main (6a0ba1189b6b). https://bugs.webkit.org/show_bug.cgi?id=275536

    Web Inspector: Uncaught Exception: null is not an object (evaluating 'styleable.node')
    https://bugs.webkit.org/show_bug.cgi?id=275536

    Reviewed by Richard Robinson.

    * Source/WebInspectorUI/UserInterface/Views/AnimationContentView.js:
    (WI.AnimationContentView.prototype._refreshSubtitle):

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

Canonical link: https://commits.webkit.org/274313.425@webkitglib/2.44


  Commit: 2cc9dc126f9113d117818c06b1f914ad81eaf56b
      https://github.com/WebKit/WebKit/commit/2cc9dc126f9113d117818c06b1f914ad81eaf56b
  Author: Carlos Garcia Campos <cgarcia at igalia.com>
  Date:   2024-09-06 (Fri, 06 Sep 2024)

  Changed paths:
    M Source/WebKit/Platform/IPC/SharedBufferReference.cpp
    M Source/WebKit/Platform/IPC/SharedBufferReference.h
    M Source/WebKit/UIProcess/WebPageProxy.cpp

  Log Message:
  -----------
  Cherry-pick 283254 at main (ea6f3ad7b704). https://bugs.webkit.org/show_bug.cgi?id=275087

    REGRESSION(274563 at main): [GTK] Broke webkit_web_resource_get_data() on https://register.gitlab.gnome.org/
    https://bugs.webkit.org/show_bug.cgi?id=275087

    Reviewed by Chris Dumez.

    Always make the buffer contiguous in SharedBufferReference::span() if
    needed. The callers of SharedBufferReference::span() always expect the
    buffer data without having to know whether the internal buffer is
    contiguous or not.

    * Source/WebKit/Platform/IPC/SharedBufferReference.cpp:
    (IPC::SharedBufferReference::span const):
    * Source/WebKit/Platform/IPC/SharedBufferReference.h:
    * Source/WebKit/UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::getLoadDecisionForIcon):

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

Canonical link: https://commits.webkit.org/274313.426@webkitglib/2.44


  Commit: fd73f137dcc66fd5c7146c3d9578346e77ae6d0a
      https://github.com/WebKit/WebKit/commit/fd73f137dcc66fd5c7146c3d9578346e77ae6d0a
  Author: Adrian Perez de Castro <aperez at igalia.com>
  Date:   2024-09-06 (Fri, 06 Sep 2024)

  Changed paths:
    M Source/WebKit/wpe/NEWS
    M Source/cmake/OptionsWPE.cmake

  Log Message:
  -----------
  Unreviewed. Update OptionsWPE.cmake and NEWS for the 2.44.4 release

* Source/WebKit/wpe/NEWS: Add release notes.
* Source/cmake/OptionsWPE.cmake: Bump version numbers.

Canonical link: https://commits.webkit.org/274313.427@webkitglib/2.44


Compare: https://github.com/WebKit/WebKit/compare/2d09b43768b7...fd73f137dcc6

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


More information about the webkit-changes mailing list