[webkit-changes] [WebKit/WebKit] 32bbe7: Cherry-pick 268964 at main (3f64447f2aa9). https://bu...

[Sammy Gill]

  Branch: refs/heads/webkitglib/2.42
  Home:   https://github.com/WebKit/WebKit
  Commit: 32bbe7e94a21ddf2bf74fcaaa197bca0f95ca245
      https://github.com/WebKit/WebKit/commit/32bbe7e94a21ddf2bf74fcaaa197bca0f95ca245
  Author: Ahmad Saleem <ahmad.saleem792+github at gmail.com>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M Source/WebCore/html/canvas/CanvasPath.cpp
    M Source/WebCore/platform/graphics/cg/PathCG.cpp
    M Source/WebCore/platform/graphics/transforms/AffineTransform.cpp
    M Source/WebCore/platform/graphics/transforms/AffineTransform.h
    M Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp
    M Source/WebCore/platform/graphics/transforms/TransformationMatrix.h

  Log Message:
  -----------
  Cherry-pick 268964 at main (3f64447f2aa9). https://bugs.webkit.org/show_bug.cgi?id=262718

    Introduce 'rotateRadians' helper function and use across WebKit

    https://bugs.webkit.org/show_bug.cgi?id=262718

    Reviewed by Chris Dumez.

    Merge: https://src.chromium.org/viewvc/blink?view=revision&revision=167603 &
    https://src.chromium.org/viewvc/blink?revision=168929&view=revision

    Currently, rotate function takes an argument in only degrees.
    In many cases, rotate function is often required radian value instead of degree value.
    If we add new rotateRadians function, we will be able to reduce unnecessary operations.

     Before : rad -> rad2deg -> deg2rad -> calc sinNcos
     After  : rad                       -> calc sinNcos

    As a result, we can reduce two multiplication and two division.

    Additionally, we can use it across WebCore source instead of 'rotate(rad2deg)'.

    * Source/WebCore/platform/graphics/transforms/AffineTransform.cpp:
    (AffineTransform::rotate):
    (AffineTransform::rotateRadians):
    (AffineTransform::rotateFromVector):
    (AffineTransform::decompose):
    * Source/WebCore/platform/graphics/transforms/AffineTransform.h: new 'rotateRadians' function
    * Source/WebCore/platform/graphics/cg/PathCG.cpp:
    (PathCG::addEllipse):
    * Source/WebCore/html/canvas/CanvasPath.cpp:
    (CanvasPath::addEllipse):
    * Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp:
    (TransformationMatrix::rotateFromVector):
    (TransformationMatrix::rotate):
    (TransformationMatrix::rotateRadians):
    * Source/WebCore/platform/graphics/transforms/TransformationMatrix.h: new 'rotateRadians' function

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


  Commit: 45dfc447957ae9284dacc33cd99be2d36880166c
      https://github.com/WebKit/WebKit/commit/45dfc447957ae9284dacc33cd99be2d36880166c
  Author: Matt Woodrow <mattwoodrow at apple.com>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/graphics/transforms/RotateTransformOperation.h
    M Source/WebCore/platform/graphics/transforms/TransformOperation.h
    M Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp
    M Source/WebCore/platform/graphics/transforms/TransformationMatrix.h

  Log Message:
  -----------
  Cherry-pick 270294 at main (84aabd280f9a). https://bugs.webkit.org/show_bug.cgi?id=263569

    REGRESSION (266237 at main): Poster circle animation is not continuous
    https://bugs.webkit.org/show_bug.cgi?id=263569
    <rdar://117209302>

    Reviewed by Simon Fraser.

    This is the same as the existing hasBig3DRotation rotation issue, where CA animates the shortest path between 3d rotations,
    because we represent them as matrices.

    Previously our computed matrices for rotate(180deg) didn’t have integer values, due to a float rounding issue during deg->rad.

    The new change computes the rotation matrix exactly, and now there’s no longer a defined direction for a 180deg rotation and
    we sometimes end up with a ‘backwards’ rotation.

    This adds an option to not do the snapping when we compute matrices for CA, so that the existing behavior is preserved.

    * Source/WebCore/platform/graphics/transforms/RotateTransformOperation.h:
    * Source/WebCore/platform/graphics/transforms/TransformOperation.h:
    (WebCore::TransformOperation::applyUnrounded const):
    * Source/WebCore/platform/graphics/transforms/TransformationMatrix.cpp:
    (WebCore::TransformationMatrix::rotate3d):
    (WebCore::TransformationMatrix::rotate):
    (WebCore::TransformationMatrix::rotateRadians):
    * Source/WebCore/platform/graphics/transforms/TransformationMatrix.h:

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


  Commit: 549cfbd671b3f61fb2ac7a30b4434a2850b7ae2a
      https://github.com/WebKit/WebKit/commit/549cfbd671b3f61fb2ac7a30b4434a2850b7ae2a
  Author: Ryosuke Niwa <rniwa at webkit.org>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M Source/WebCore/dom/EventPath.cpp

  Log Message:
  -----------
  Cherry-pick 270295 at main (6fa5837d95d9). https://bugs.webkit.org/show_bug.cgi?id=264380

    nullptr crash in EventPath::eventTargetRespectingTargetRules via EventPath::buildPath
    https://bugs.webkit.org/show_bug.cgi?id=264276
    <rdar://117902151>

    Reviewed by Chris Dumez.

    Add a nullptr check where the crash occurs. Also add a debug assert since this node
    should never be nullptr in theory.

    * Source/WebCore/dom/EventPath.cpp:
    (WebCore::EventPath::buildPath):

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


  Commit: 53d71b7ffd1d9c2ff7eda0499d16f7f4114dbb52
      https://github.com/WebKit/WebKit/commit/53d71b7ffd1d9c2ff7eda0499d16f7f4114dbb52
  Author: Jean-Yves Avenard <jya at apple.com>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M Source/JavaScriptCore/assembler/testmasm.cpp

  Log Message:
  -----------
  Cherry-pick 270371 at main (1755d48a638b). https://bugs.webkit.org/show_bug.cgi?id=264380

    Fix compilation failures on ARM64 linux
    https://bugs.webkit.org/show_bug.cgi?id=264380
    rdar://118093158

    Reviewed by Yusuke Suzuki.

    Fixing a few "error: comparison of unsigned expression in ‘>= 0’ is always true [-Werror=type-limits]"
    and "error: suggest parentheses around ‘-’ in operand of ‘&’ [-Werror=parentheses]".

    * Source/JavaScriptCore/assembler/testmasm.cpp:
    (JSC::testExtractUnsignedBitfield64):
    (JSC::testInsertUnsignedBitfieldInZero32):
    (JSC::testInsertUnsignedBitfieldInZero64):
    (JSC::testInsertBitField32):
    (JSC::testInsertBitField64):
    (JSC::testExtractInsertBitfieldAtLowEnd32):
    (JSC::testExtractInsertBitfieldAtLowEnd64):
    (JSC::testClearBitField32):
    (JSC::testClearBitField64):
    (JSC::testInsertSignedBitfieldInZero32):
    (JSC::testInsertSignedBitfieldInZero64):
    (JSC::testExtractSignedBitfield32):
    (JSC::testExtractSignedBitfield64):
    (JSC::testExtractRegister32):
    (JSC::testExtractRegister64):
    (JSC::testZeroExtend48ToWord):

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


  Commit: 7d947bce6fbef4a3cc43d7db98a2221243e02fb1
      https://github.com/WebKit/WebKit/commit/7d947bce6fbef4a3cc43d7db98a2221243e02fb1
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M Source/WebCore/page/csp/ContentSecurityPolicy.cpp

  Log Message:
  -----------
  Cherry-pick 270393 at main (de7073050171). https://bugs.webkit.org/show_bug.cgi?id=264372

    Crash under ContentSecurityPolicy::reportViolation()
    https://bugs.webkit.org/show_bug.cgi?id=264372
    rdar://117727308

    Reviewed by David Kilzer.

    The code was doing an early return in this case:
    ```
    if (!usesReportTo && !is<Document>(m_scriptExecutionContext))
        return;
    ```
    Then proceeding to downcast m_scriptExecutionContext to a Document.
    This meant we would do a bad cast in the case where usesReportTo is
    true.

    * Source/WebCore/page/csp/ContentSecurityPolicy.cpp:
    (WebCore::ContentSecurityPolicy::reportViolation const):

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


  Commit: 958bda05b0b856f9cf2990e9cd64e7b16bc51602
      https://github.com/WebKit/WebKit/commit/958bda05b0b856f9cf2990e9cd64e7b16bc51602
  Author: Jean-Yves Avenard <jya at apple.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/WebCore/dom/TreeScope.cpp
    M Source/WebCore/dom/TreeScopeOrderedMap.cpp

  Log Message:
  -----------
  Cherry-pick 270421 at main (f738f4311526). https://bugs.webkit.org/show_bug.cgi?id=264442

    Compilation failure using gcc (GCC) 13.2.1 20231011 (Red Hat 13.2.1-4)
    https://bugs.webkit.org/show_bug.cgi?id=264442
    rdar://118141764

    Reviewed by Alex Christensen.

    Fix compilation error "error: possibly dangling reference to a temporary [-Werror=dangling-reference]"
    No change in observable behaviour.

    * Source/WebCore/dom/TreeScope.cpp:
    (WebCore::TreeScope::findAnchor):
    * Source/WebCore/dom/TreeScopeOrderedMap.cpp:
    (WebCore::TreeScopeOrderedMap::get const):

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


  Commit: 60a14f2bc6ebb7b60e1bd8a4b47d820bff115c2b
      https://github.com/WebKit/WebKit/commit/60a14f2bc6ebb7b60e1bd8a4b47d820bff115c2b
  Author: Yijia Huang <yijia_huang at apple.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    A JSTests/stress/dfg-add-int32-var-with-const-double.js
    M Source/JavaScriptCore/dfg/DFGGraph.h

  Log Message:
  -----------
  Cherry-pick 270481 at main (79a659d55c63). https://bugs.webkit.org/show_bug.cgi?id=264278

    [JSC] Fix addImmediateShouldSpeculateInt32 for case int32 + constant double
    https://bugs.webkit.org/show_bug.cgi?id=264278
    rdar://117563215

    Reviewed by Yusuke Suzuki.

    Current fixup phase would convert the DFG node

        ValueAdd(Int32, DoubleConstant)

    to

        ArithAdd(Int32, JSConstant(DoubleConstant))

    if the node is OK to be truncated to Int32. This is
    wrong. For example, let Int32 be -1 and DoubleConstant
    be 0.1 where

        ToInt32(-1 + 0.1) == 0

    but

        -1 + ToInt32(0.1) == -1

    . So, we should not speculate that node with Int32 in this case.

    * JSTests/stress/dfg-int32-add-non-int-double.js: Added.
    (foo):
    * Source/JavaScriptCore/dfg/DFGGraph.h:

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


  Commit: eb16a5121592036ad32f109c6237de2cd35f9bb4
      https://github.com/WebKit/WebKit/commit/eb16a5121592036ad32f109c6237de2cd35f9bb4
  Author: Marek Vasut <marex at denx.de>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

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

  Log Message:
  -----------
  Cherry-pick 270593 at main (76bc3f4aa793). https://bugs.webkit.org/show_bug.cgi?id=264398

    [GStreamer] Ignore early EOS only when not looping
    https://bugs.webkit.org/show_bug.cgi?id=264398

    Reviewed by Philippe Normand.

    When playing video in a loop using HTML5 video element, the Gstreamer
    debug log sometimes contains the following message, which prevents the
    WPE from correctly stopping the playback before restarting it for the
    next loop and the playback ends up paused forever:

    ```
    webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:1851:handleMessage:<video-1> EOS received but position {23823333333/1000000000 = 23.823333333} is still in the finite playable limits [{0/1 = 0}, {23828333333/1000000000 = 23.828333333}], ignoring it
    ```

    Ignore early EOS only when not looping, otherwise unconditionally
    indicate the stream has ended.

    * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::handleMessage):

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


  Commit: 97ea7037cd8b4287b341f071b9efd308034cd4ba
      https://github.com/WebKit/WebKit/commit/97ea7037cd8b4287b341f071b9efd308034cd4ba
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/encryptedmedia/CDMProxy.cpp

  Log Message:
  -----------
  Cherry-pick 270627 at main (d0b51b0807c8). https://bugs.webkit.org/show_bug.cgi?id=264705

    [GStreamer][EME][Debug] Flaky assertions on weak pointer
    https://bugs.webkit.org/show_bug.cgi?id=264705

    Reviewed by Xabier Rodriguez-Calvar.

    Replace ASSERTs on WeakPtr by runtime checks, the pointer can be null, it's a valid scenario, so it
    shouldn't be in an ASSERT.

    * Source/WebCore/platform/encryptedmedia/CDMProxy.cpp:
    (WebCore::CDMInstanceProxy::startedWaitingForKey):
    (WebCore::CDMInstanceProxy::stoppedWaitingForKey):

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


  Commit: ee916310d051471df88eee07a636780cd3032598
      https://github.com/WebKit/WebKit/commit/ee916310d051471df88eee07a636780cd3032598
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

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

  Log Message:
  -----------
  Cherry-pick 270629 at main (9c761fded496). https://bugs.webkit.org/show_bug.cgi?id=264707

    [GStreamer] MediaPlayer's codecs hashmap needs protection
    https://bugs.webkit.org/show_bug.cgi?id=264707

    Reviewed by Xabier Rodriguez-Calvar.

    The m_codecs HashMap can be accessed from multiple threads, so it needs to be protected by a mutex.

    * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::setupCodecProbe):
    (WebCore::MediaPlayerPrivateGStreamer::codecForStreamId):
    * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:

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


  Commit: b00dfb7a1840c2e423ab9da0fa1c7ca39ccee8b8
      https://github.com/WebKit/WebKit/commit/b00dfb7a1840c2e423ab9da0fa1c7ca39ccee8b8
  Author: Antti Koivisto <antti at apple.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/WebCore/rendering/TextBoxPainter.cpp

  Log Message:
  -----------
  Cherry-pick 270634 at main (f9ec06b716a3). https://bugs.webkit.org/show_bug.cgi?id=264728

    Crash under TextBoxPainter<WebCore::InlineIterator::BoxModernPath>::collectDecoratingBoxesForTextBox
    https://bugs.webkit.org/show_bug.cgi?id=264728
    rdar://117897402

    Reviewed by Alan Baradlay.

    * Source/WebCore/rendering/TextBoxPainter.cpp:
    (WebCore::TextBoxPainter<TextBoxPath>::collectDecoratingBoxesForTextBox):

    There appears to be some case where parentInlineBox is not found. Add null checking.

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


  Commit: 9ffd7a92e89c4004e299f333a2c617493325231f
      https://github.com/WebKit/WebKit/commit/9ffd7a92e89c4004e299f333a2c617493325231f
  Author: David Kilzer <ddkilzer at apple.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/ThirdParty/libwebrtc/Source/webrtc/modules/rtp_rtcp/source/receive_statistics_impl.cc
    M Source/ThirdParty/libwebrtc/Source/webrtc/test/fuzzers/utils/rtp_replayer.cc

  Log Message:
  -----------
  Cherry-pick 270656 at main (01dea93c203e). https://bugs.webkit.org/show_bug.cgi?id=264718

    Avoid divide-by-zero in webrtc::StreamStatisticianImpl::BitrateReceived
    https://bugs.webkit.org/show_bug.cgi?id=264718
    <rdar://117912996>

    Reviewed by Youenn Fablet.

    Merge upstream 7dbf55437f109cb13d131d91ba645029686fa247 by
    Harald Alvestrand <hta at webrtc.org>.

    * Source/ThirdParty/libwebrtc/Source/webrtc/modules/rtp_rtcp/source/receive_statistics_impl.cc:
    * Source/ThirdParty/libwebrtc/Source/webrtc/test/fuzzers/utils/rtp_replayer.cc:

    --

    Ensure payload type frequency does not cause divide-by-zero

    This CL does 2 things:
    - Change the DCHECK for payload_type_frequency to a CHECK (so that
    this error will be a crash not a divide-by-zero)
    - Change the replay helper that was used by the fuzzer to set the
    frequency of the packets to the video value (90K).

    Bug: chromium:1466826
    Change-Id: I39941f250b1782b36a3bcddfd347a016591466ec
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312700
    Commit-Queue: Harald Alvestrand <hta at webrtc.org>
    Reviewed-by: Danil Chapovalov <danilchap at webrtc.org>
    Cr-Commit-Position: refs/heads/main@{#40468}
    Canonical link: https://commits.webkit.org/270656@main


  Commit: 4e521e2a3b223800bdc3931dab7e104a9e34c897
      https://github.com/WebKit/WebKit/commit/4e521e2a3b223800bdc3931dab7e104a9e34c897
  Author: Yury Semikhatsky <yurys at chromium.org>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/JavaScriptCore/inspector/InjectedScript.cpp
    M Source/JavaScriptCore/inspector/InjectedScriptBase.cpp
    M Source/JavaScriptCore/inspector/InjectedScriptModule.cpp

  Log Message:
  -----------
  Cherry-pick 270739 at main (a4eed62b176c). https://bugs.webkit.org/show_bug.cgi?id=165875

    ScriptFunctionCall::call() can return an empty JSValue if the watchdog timer fires, callers should check for this
    https://bugs.webkit.org/show_bug.cgi?id=165875

    Reviewed by Devin Rousso.

    ScriptFunctionCall::call() may return empty JSValue from several places,
    the callers now check for emptiness first before accessing the value.

    Unfortunately, I don't have a reliable repro which could be converted
    to a layout test like the one in https://github.com/WebKit/WebKit/commit/11d211bca821fa4803d6da95c857a04b7f32c46a
    even though the symptoms are similar.

    * Source/JavaScriptCore/inspector/InjectedScript.cpp:
    (Inspector::InjectedScript::wrapObject const):
    (Inspector::InjectedScript::wrapJSONString const):
    (Inspector::InjectedScript::wrapTable const):
    (Inspector::InjectedScript::previewValue const):
    (Inspector::InjectedScript::createCommandLineAPIObject const):

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


  Commit: 60afb603bffe5715c37ccc8574eafcaaaece1e52
      https://github.com/WebKit/WebKit/commit/60afb603bffe5715c37ccc8574eafcaaaece1e52
  Author: Przemyslaw Gorszkowski <pgorszkowski at igalia.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    A LayoutTests/fast/dom/dynamic-image-with-lazy-loading-leak-expected.txt
    A LayoutTests/fast/dom/dynamic-image-with-lazy-loading-leak.html
    M Source/WebCore/loader/ImageLoader.cpp
    M Source/WebCore/loader/ImageLoader.h

  Log Message:
  -----------
  Cherry-pick 270745 at main (78e4577732ca). https://bugs.webkit.org/show_bug.cgi?id=263521

    Memory consumption/leak with img out of viewport and lazy loading
    https://bugs.webkit.org/show_bug.cgi?id=263521

    Reviewed by Chris Dumez.

    This change fixes the problem with dangling of dynamically created (in JS)
    HTMLImageElement when it is detached from the document before loading the resource
    starts. It happened when img element was created (dynamically) with lazy loading
    and the element was outside the viewport (the loading of resource is deferred until
    the img element becomes visible). If the element was removed from document it
    becomes dangling element and will never be deleted by GC.

    * Source/WebCore/loader/ImageLoader.cpp:
    (WebCore::ImageLoader::hasPendingActivity const):

    To avoid leaking of the dynamically created element, the pending activity of
    the element should check has the load of the resource actually started.
    Similar check is done in case of static HTMLImageElement in
    ImageLoader::updatedHasPendingEvent.

    * Source/WebCore/loader/ImageLoader.h:
    (WebCore::ImageLoader::hasPendingActivity const): Deleted.

    Moved implementation to cpp file.

     * LayoutTests/fast/dom/dynamic-image-with-lazy-loading-leak-expected.txt: Added.
     * LayoutTests/fast/dom/dynamic-image-with-lazy-loading-leak.html: Added.

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


  Commit: 00ff125e5b0ce6369b7fb40fc1edd0378389bfe9
      https://github.com/WebKit/WebKit/commit/00ff125e5b0ce6369b7fb40fc1edd0378389bfe9
  Author: Vitaly Dyachkov <vitaly at igalia.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M LayoutTests/platform/glib/TestExpectations
    M Source/WebCore/dom/Node.h
    M Source/WebCore/dom/Position.h

  Log Message:
  -----------
  Cherry-pick 270763 at main (3855bdaf1c1b). https://bugs.webkit.org/show_bug.cgi?id=164053

    ASSERTION FAILED: !((anchorType == PositionIsBeforeChildren || anchorType == PositionIsAfterChildren) && (is<Text>(*m_anchorNode) || editingIgnoresContent(*m_anchorNode))) in WebCore::Position::Position
    https://bugs.webkit.org/show_bug.cgi?id=164053

    Reviewed by Ryosuke Niwa.

    Since `firstPositionInNode()` and `lastPositionInNode()` take any node
    as their argument, including `Comment`, we should use
    `PositionIsOffsetInAnchor` for any `CharacterData`, not only for `Text`.

    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/dom/Node.h:
    (WebCore::Node::isCharacterData const):
    * Source/WebCore/dom/Position.h:
    (WebCore::firstPositionInNode):
    (WebCore::lastPositionInNode):

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


  Commit: 20a9a771a25121f1661cd26d87c78c97c368f7ac
      https://github.com/WebKit/WebKit/commit/20a9a771a25121f1661cd26d87c78c97c368f7ac
  Author: Vitaly Dyachkov <vitaly at igalia.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/WebCore/page/LocalFrameView.cpp
    M Source/WebCore/page/LocalFrameView.h
    M Source/WebCore/platform/ScrollableArea.cpp

  Log Message:
  -----------
  Cherry-pick 270820 at main (50aa99222474). https://bugs.webkit.org/show_bug.cgi?id=259912

    [WPE][Debug] ASSERTION FAILED: inProgrammaticScroll == (options.type == ScrollType::Programmatic)
    https://bugs.webkit.org/show_bug.cgi?id=259912

    Reviewed by Simon Fraser.

    In `AsyncScrollingCoordinator::requestScrollToPosition()` we assert
    that the `scrollableArea`'s `currentScrollType()` matches the
    `ScrollPositionChangeOptions`'s type.

    In some circumstances, this method can be called as a result of
    calling `ScrollableArea::scrollToPositionWithAnimation()`, which
    currently doesn't set its `currentScrollType` from `options` argument.

    `LocalFrameView`, which is a subclass of `ScrollableArea`, adds a method
    whose only job is to set/restore `currentScrollType` and call parent's
    method. We can move this logic to the `ScrollableArea` class. There's
    actually a FIXME about this.

    * Source/WebCore/page/LocalFrameView.cpp:
    (WebCore::LocalFrameView::scrollToPositionWithAnimation): Deleted.
    * Source/WebCore/page/LocalFrameView.h:
    * Source/WebCore/platform/ScrollableArea.cpp:
    (WebCore::ScrollableArea::scrollToPositionWithAnimation):

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


  Commit: 8923374e248da31f63b59b7e104614d128c85055
      https://github.com/WebKit/WebKit/commit/8923374e248da31f63b59b7e104614d128c85055
  Author: Olivier Blin <olivier.blin at softathome.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

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

  Log Message:
  -----------
  Cherry-pick 270877 at main (734a5ac349df). https://bugs.webkit.org/show_bug.cgi?id=264941

    [GStreamer] Avoid using decoding limits for all configurations
    https://bugs.webkit.org/show_bug.cgi?id=264941

    Reviewed by Philippe Normand.

    When VIDEO_DECODING_LIMIT support is enabled, after a first call of
    isContentTypeSupported() with Configuration::Decoding, the video
    limits are remembered in a static variable.

    They were then used for all subsequent isContentTypeSupported() calls,
    regardless of the configuration.

    This should be limited to Configuration::Decoding.

    * Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
    (WebCore::GStreamerRegistryScanner::isContentTypeSupported const):

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


  Commit: 1df901ec8621c3e41267f13a195714228cdcbc0e
      https://github.com/WebKit/WebKit/commit/1df901ec8621c3e41267f13a195714228cdcbc0e
  Author: Olivier Blin <olivier.blin at softathome.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/audio/gstreamer/AudioSourceProviderGStreamer.h

  Log Message:
  -----------
  Cherry-pick 270898 at main (579a9e5c3ee4). https://bugs.webkit.org/show_bug.cgi?id=265039

    Fix AudioSourceProviderGStreamer build with !ENABLE(MEDIA_STREAM)
    https://bugs.webkit.org/show_bug.cgi?id=265039

    Reviewed by Philippe Normand.

    * Source/WebCore/platform/audio/gstreamer/AudioSourceProviderGStreamer.h:
    WebAudioSourceProvider.h always needs to be included since
    AudioSourceProviderGStreamer inherits from WebAudioSourceProvider.

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


  Commit: ab51672c66ca0a4a74d418cab0e5fce6104201aa
      https://github.com/WebKit/WebKit/commit/ab51672c66ca0a4a74d418cab0e5fce6104201aa
  Author: Youenn Fablet <youennf at gmail.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    A LayoutTests/http/wpt/workers/font-loading-error.any-expected.txt
    A LayoutTests/http/wpt/workers/font-loading-error.any.html
    A LayoutTests/http/wpt/workers/font-loading-error.any.js
    A LayoutTests/http/wpt/workers/font-loading-error.any.worker-expected.txt
    A LayoutTests/http/wpt/workers/font-loading-error.any.worker.html
    M Source/WebCore/dom/DocumentFontLoader.cpp
    M Source/WebCore/workers/WorkerFontLoadRequest.cpp

  Log Message:
  -----------
  Cherry-pick 271213 at main (b1f4d8147c3c). https://bugs.webkit.org/show_bug.cgi?id=265000

    FontFace with data: URI crashes Worker
    https://bugs.webkit.org/show_bug.cgi?id=265000
    rdar://118546120

    Reviewed by Alex Christensen.

    Make sure to reject the promise when font loading fails in a worker.
    Align implementation with spec on data URL font loading by allowing them.

    * LayoutTests/http/wpt/workers/font-loading-error.any-expected.txt: Added.
    * LayoutTests/http/wpt/workers/font-loading-error.any.html: Added.
    * LayoutTests/http/wpt/workers/font-loading-error.any.js: Added.
    (promise_test.async return):
    (promise_test):
    * LayoutTests/http/wpt/workers/font-loading-error.any.worker-expected.txt: Added.
    * LayoutTests/http/wpt/workers/font-loading-error.any.worker.html: Added.
    * Source/WebCore/dom/DocumentFontLoader.cpp:
    (WebCore::DocumentFontLoader::cachedFont):
    * Source/WebCore/workers/WorkerFontLoadRequest.cpp:
    (WebCore::WorkerFontLoadRequest::load):
    (WebCore::WorkerFontLoadRequest::didFail):

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


  Commit: 92db624c4fa87d9ff0e67e8ab4785b8a9780e033
      https://github.com/WebKit/WebKit/commit/92db624c4fa87d9ff0e67e8ab4785b8a9780e033
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

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

  Log Message:
  -----------
  Cherry-pick 271374 at main (0143c180fd5a). https://bugs.webkit.org/show_bug.cgi?id=264663

    [GStreamer][MSE] media/media-source/media-source-webm-configuration-framerate.html is flaky crash
    https://bugs.webkit.org/show_bug.cgi?id=264663

    Reviewed by Xabier Rodriguez-Calvar.

    Check the m_source GRefPtr is non-null when handling the stream-collection message. It might be
    cleared while the player is getting disposed. The whole method cannot be called from a WeakPtr
    player without causing deadlocks, sadly.

    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::handleStreamCollectionMessage):

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


  Commit: 0a74b85dcbbb8c2f41a6f40a0aa70a18d133088e
      https://github.com/WebKit/WebKit/commit/0a74b85dcbbb8c2f41a6f40a0aa70a18d133088e
  Author: Mark Lam <mark.lam at apple.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    A JSTests/stress/out-of-memory-while-describing-symbol-for-error.js
    M Source/JavaScriptCore/runtime/ExceptionHelpers.cpp
    M Source/JavaScriptCore/runtime/Symbol.cpp
    M Source/JavaScriptCore/runtime/Symbol.h

  Log Message:
  -----------
  Cherry-pick 271458 at main (d1f1209a4e20). https://bugs.webkit.org/show_bug.cgi?id=265775

    Gracefully handle OOM while trying to describing a Symbol when creating an Error.
    https://bugs.webkit.org/show_bug.cgi?id=265775
    rdar://119046215

    Reviewed by Yusuke Suzuki.

    If trying to describe a Symbol via stringifying it results in an OutOfMemoryError,
    just simply describe is as a generic "Symbol" instead.

    * JSTests/stress/out-of-memory-while-describing-symbol-for-error.js: Added.
    (catch):
    * Source/JavaScriptCore/runtime/ExceptionHelpers.cpp:
    (JSC::errorDescriptionForValue):
    * Source/JavaScriptCore/runtime/Symbol.cpp:
    (JSC::Symbol::tryGetDescriptiveString const):
    * Source/JavaScriptCore/runtime/Symbol.h:

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


  Commit: 035bf46b6b11c32f0af0c6b21e0ec5639e69a595
      https://github.com/WebKit/WebKit/commit/035bf46b6b11c32f0af0c6b21e0ec5639e69a595
  Author: Ahmad Saleem <ahmad.saleem792+github at gmail.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/LayoutUnit.h
    M Tools/TestWebKitAPI/Tests/WebCore/LayoutUnitTests.cpp

  Log Message:
  -----------
  Cherry-pick 271550 at main (2c3e402a8ea0). https://bugs.webkit.org/show_bug.cgi?id=265825

    Avoid integer overflow in LayoutUnit's unary minus operator

    https://bugs.webkit.org/show_bug.cgi?id=265825

    Reviewed by Alan Baradlay.

    Merge: https://chromium.googlesource.com/chromium/src.git/+/ef6bea224f0266018c3b4fc63262769020b9a4c2

    This PR fixes potential 'integer overflow' leading to crashes (in debug or fuzzer)
    environments.

    * Source/WebCore/platform/LayoutUnit.h:
    (operator-):
    * Tools/TestWebKitAPI/Tests/WebCore/LayoutUnitTests.cpp: Add Test Case 'LayoutUnitUnaryMinus'

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


  Commit: a5b4a520cb59549573a0c746289bc34d2ce02da4
      https://github.com/WebKit/WebKit/commit/a5b4a520cb59549573a0c746289bc34d2ce02da4
  Author: Matt Woodrow <mattwoodrow at apple.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    A LayoutTests/compositing/layer-creation/overlap-transformed-clip-expected.html
    A LayoutTests/compositing/layer-creation/overlap-transformed-clip.html
    M Source/WebCore/rendering/RenderLayer.cpp
    M Source/WebCore/rendering/RenderLayer.h
    M Source/WebCore/rendering/RenderLayerBacking.cpp

  Log Message:
  -----------
  Cherry-pick 271894 at main (cc12d007e2e9). https://bugs.webkit.org/show_bug.cgi?id=265480

    Second div within a rotated and overflow:hidden parent div does not render.
    https://bugs.webkit.org/show_bug.cgi?id=265480
    <rdar://118901069>

    Reviewed by Simon Fraser.

    RenderLayerCompositor::addToOverlapMap takes layer overlap bounds in the root coordinate space, computes
    the clip in the root coordinate space and intersect them.

    RenderLayer::calculateClipRects was only ever applying an offset when converting clips to an ancestor coordinate
    space, which is incorrect if there is a non-tranlation transform (like the rotation in the testcase).

    The incorrect clip resulted in an empty overlap area, and us drawing the green div into the backing store behind
    the composited (3d transformed) div.

    This makes calculateClipRects transform the clip quad, not just the top-left point.

    * LayoutTests/compositing/layer-creation/overlap-transformed-clip-expected.html: Added.
    * LayoutTests/compositing/layer-creation/overlap-transformed-clip.html: Added.
    * Source/WebCore/rendering/RenderLayer.cpp:
    (WebCore::RenderLayer::calculateClipRects const):
    * Source/WebCore/rendering/RenderLayer.h:
    * Source/WebCore/rendering/RenderLayerBacking.cpp:
    (WebCore::intersectsWithAncestor):

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


  Commit: e42893ffc38ff8adc0d9a0d36862075dfbc5a5ee
      https://github.com/WebKit/WebKit/commit/e42893ffc38ff8adc0d9a0d36862075dfbc5a5ee
  Author: Nikolas Zimmermann <nzimmermann at igalia.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    A LayoutTests/platform/glib/svg/text/textLength-tspan-in-textPath-expected.txt
    A LayoutTests/platform/ios/svg/text/textLength-tspan-in-textPath-expected.txt
    A LayoutTests/platform/mac/svg/text/textLength-tspan-in-textPath-expected.png
    A LayoutTests/platform/mac/svg/text/textLength-tspan-in-textPath-expected.txt
    A LayoutTests/svg/text/textLength-tspan-in-textPath.html
    M Source/WebCore/rendering/svg/SVGTextLayoutEngine.cpp

  Log Message:
  -----------
  Cherry-pick 271996 at main (79238bc8e2d6). https://bugs.webkit.org/show_bug.cgi?id=264184

    REGRESSION(264666 at main): Layout of the <tspan> elements inside a <textPath> is incorrect
    https://bugs.webkit.org/show_bug.cgi?id=264184

    Reviewed by Said Abou-Hallawa.

    Revision 264666 at main broke <tspan textLength="..."> behavior on <textPath> elements.
    The logic added to fix the intra-character spacing, wasn't intended for text path
    layout, where each character by definition is placed in its own box. Fix the MDN
    regression by disabling the new code paths for text-on-path layout.

    Covered by new test in svg/text/textLength-tspan-in-textPath.html.

    Unfortunately it's hard to make a cross-platform reftest, given the
    nature of the kind of test, and the missing way to layout text along
    a path in HTML/CSS.

    * LayoutTests/platform/glib/svg/text/textLength-tspan-in-textPath-expected.txt: Added.
    * LayoutTests/platform/ios/svg/text/textLength-tspan-in-textPath-expected.txt: Added.
    * LayoutTests/platform/mac/svg/text/textLength-tspan-in-textPath-expected.png: Added.
    * LayoutTests/platform/mac/svg/text/textLength-tspan-in-textPath-expected.txt: Added.
    * LayoutTests/svg/text/textLength-tspan-in-textPath.html: Added.
    * Source/WebCore/rendering/svg/SVGTextLayoutEngine.cpp:
    (WebCore::SVGTextLayoutEngine::layoutTextOnLineOrPath):

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


  Commit: 3116070d07a535db5814cf22e27329c42c23ac9f
      https://github.com/WebKit/WebKit/commit/3116070d07a535db5814cf22e27329c42c23ac9f
  Author: Eric Carlson <eric.carlson at apple.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/WebCore/html/track/VTTScanner.cpp
    M Source/WebCore/html/track/VTTScanner.h

  Log Message:
  -----------
  Cherry-pick 272005 at main (976e6341b4a8). https://bugs.webkit.org/show_bug.cgi?id=266355

    VTTScanner should copy the string it is parsing
    https://bugs.webkit.org/show_bug.cgi?id=266355
    rdar://119621360

    Reviewed by Chris Dumez.

    Store the String to be parsed in a member variable instead of only storing pointers to the
    start and end of the String to avoid crashes like the one caused by caused by 270868 at main.

    * Source/WebCore/html/track/VTTScanner.cpp:
    (WebCore::VTTScanner::VTTScanner):
    * Source/WebCore/html/track/VTTScanner.h:

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


  Commit: 6afbe913b5b663f45938c9e026b0aa52bf746b52
      https://github.com/WebKit/WebKit/commit/6afbe913b5b663f45938c9e026b0aa52bf746b52
  Author: Mark Lam <mark.lam at apple.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/JavaScriptCore/llint/LLIntOpcode.h
    M Source/JavaScriptCore/llint/LowLevelInterpreter.cpp

  Log Message:
  -----------
  Cherry-pick 272012 at main (aa62ce7b9059). https://bugs.webkit.org/show_bug.cgi?id=266294

    BYTECODE_HELPER_ID LLint opcodes need look up for wide versions.
    https://bugs.webkit.org/show_bug.cgi?id=266294
    rdar://119563251

    Reviewed by Justin Michaud.

    FOR_EACH_BYTECODE_HELPER_ID was mistakenly lumped in with FOR_EACH_LLINT_NATIVE_HELPER, which
    does not populate their entries in g_opcodeMapWide16 and g_opcodeMapWide32.  This patch fixes
    that.

    This was causing CLoop runs to crash on nullptr derefs on these non-initialized entries.

    * Source/JavaScriptCore/llint/LLIntOpcode.h:
    * Source/JavaScriptCore/llint/LowLevelInterpreter.cpp:
    (JSC::CLoop::execute):

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


  Commit: 78b6821d76ed2889788e1215b883247a74267894
      https://github.com/WebKit/WebKit/commit/78b6821d76ed2889788e1215b883247a74267894
  Author: Youenn Fablet <youennf at gmail.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M Source/WebKit/NetworkProcess/cache/NetworkCacheSubresourcesEntry.h

  Log Message:
  -----------
  Cherry-pick 272062 at main (3096c561acce). https://bugs.webkit.org/show_bug.cgi?id=265634

    Samesite=Lax is not always working in Safari
    https://bugs.webkit.org/show_bug.cgi?id=265634
    rdar://119362503

    Reviewed by Brent Fulgham and Alex Christensen.

    We were not setting isSameSite correctly when reading it from disk cache, which was then triggering different cookies being sent between
    speculative loads and the actual would be loads.
    Websites could use Vary Cookie headers to handle that case, but they do not tend to.

    * Source/WebKit/NetworkProcess/cache/NetworkCacheSubresourcesEntry.h:
    (WebKit::NetworkCache::SubresourceInfo::SubresourceInfo):

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


  Commit: 9d55c4dceb7e18a287613a1ceb1c1d7d35e3b751
      https://github.com/WebKit/WebKit/commit/9d55c4dceb7e18a287613a1ceb1c1d7d35e3b751
  Author: Sammy Gill <sammy.gill at apple.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    A LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows-expected.html
    A LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows.html
    A LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows-expected.html
    A LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows.html
    M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp

  Log Message:
  -----------
  Cherry-pick 272085 at main (cf2a9868136a). https://bugs.webkit.org/show_bug.cgi?id=260201

    REGRESSION(261003 at main): [css-contain][css-grid] Size containment is not allowing the track sizing algorithm to distribute extra space to auto tracks
    https://bugs.webkit.org/show_bug.cgi?id=260201
    rdar://problem/113915953

    Reviewed by Brent Fulgham.

    Size containment is supposed to size a box as if it had no content, so
    for the purposes of grid layout this would mean that we would want to
    skip parts of the algorithm that take into consideration the content.

    The "Stretch auto Tracks," portion of the grid track sizing algorithm
    should not be skipped, however, as it has nothing to do with the content
    of the grid. We should be able to distribute any definite free space
    that we computed up to this point.

    * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows-expected.html: Added.
    * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-grid-stretches-auto-rows.html: Added.
    * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows-expected.html: Added.
    * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-size-grid-stretches-auto-rows.html: Added.
    * Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
    (WebCore::GridTrackSizingAlgorithm::run):

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


Compare: https://github.com/WebKit/WebKit/compare/e136566934c0...9d55c4dceb7e