[webkit-changes] [WebKit/WebKit] 21a14e: Cherry-pick 274730 at main (f270bdb7b34c). https://bu...

Michael Saboff noreply at github.com
Thu May 2 03:22:28 PDT 2024


  Branch: refs/heads/webkitglib/2.44
  Home:   https://github.com/WebKit/WebKit
  Commit: 21a14e254586234eddaf9b091b9e61ee4116f566
      https://github.com/WebKit/WebKit/commit/21a14e254586234eddaf9b091b9e61ee4116f566
  Author: Xabier Rodriguez-Calvar <calvaris at igalia.com>
  Date:   2024-04-27 (Sat, 27 Apr 2024)

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

  Log Message:
  -----------
  Cherry-pick 274730 at main (f270bdb7b34c). https://bugs.webkit.org/show_bug.cgi?id=263317

    [MSE][GStreamer] Pause after seek is not working
    https://bugs.webkit.org/show_bug.cgi?id=263317

    Reviewed by Philippe Normand.

    So far we are just asking the pipeline if we were paused or not but that does not work when the pipeline is
    transitioning or seeking. That creates desynchronization between the media element and the player. We now consider the
    pipeline in the final state while it is transitioning, as it can handle other requests while at it.

    We also need to force ready state change when the pipeline finishes the state change to paused or playing because the
    player will report state changes sooner.

    This changes won't apply to MediaStream because the dynamics of prerolling are much different.

    Fly by style change in isPipelineSeeking.

    * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::isPipelineSeeking const):
    (WebCore::MediaPlayerPrivateGStreamer::paused const):
    (WebCore::MediaPlayerPrivateGStreamer::updateStates):

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

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


  Commit: abe23c2400b65f81f755a2725248642a9fda52b3
      https://github.com/WebKit/WebKit/commit/abe23c2400b65f81f755a2725248642a9fda52b3
  Author: Przemyslaw Gorszkowski <pgorszkowski at igalia.com>
  Date:   2024-04-27 (Sat, 27 Apr 2024)

  Changed paths:
    M Source/WebCore/page/UserScript.cpp
    M Source/WebCore/page/UserStyleSheet.cpp

  Log Message:
  -----------
  Cherry-pick 277533 at main (4e328a1f0c16). https://bugs.webkit.org/show_bug.cgi?id=272666

    Fix potential unified build error
    https://bugs.webkit.org/show_bug.cgi?id=272666

    Reviewed by Adrian Perez de Castro.

    The problem is the same name of global static function in two cpp files.
    This change resolves potential compiler error in unified build.

    * Source/WebCore/page/UserScript.cpp:
    (WebCore::generateUserScriptUniqueURL):
    (WebCore::UserScript::UserScript):
    (WebCore::generateUniqueURL): Deleted.
    * Source/WebCore/page/UserStyleSheet.cpp:
    (WebCore::generateUserStyleUniqueURL):
    (WebCore::UserStyleSheet::UserStyleSheet):
    (WebCore::generateUniqueURL): Deleted.

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

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


  Commit: 66fe4f6f1ede0cdabb77987423f8de3085e03c93
      https://github.com/WebKit/WebKit/commit/66fe4f6f1ede0cdabb77987423f8de3085e03c93
  Author: Xabier Rodriguez-Calvar <calvaris at igalia.com>
  Date:   2024-04-28 (Sun, 28 Apr 2024)

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

  Log Message:
  -----------
  Cherry-pick 275037 at main (3ab7997af7e5). https://bugs.webkit.org/show_bug.cgi?id=269782

    [GStreamer] Fix audio sink detection in custom platforms
    https://bugs.webkit.org/show_bug.cgi?id=269782

    Reviewed by Philippe Normand.

    Sometimes we can get a message from a new audio sink that we should store as such even when we already have one.

    Based on a patch by Pawel Lampe <pawel.lampe at gmail.com>.

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

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

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


  Commit: 1c9023f4037fb4eda161b557c1b7374b313abaee
      https://github.com/WebKit/WebKit/commit/1c9023f4037fb4eda161b557c1b7374b313abaee
  Author: Charlie Wolfe <charliew at apple.com>
  Date:   2024-04-28 (Sun, 28 Apr 2024)

  Changed paths:
    M Source/WebKit/WebProcess/WebPage/WebFrame.cpp

  Log Message:
  -----------
  Cherry-pick 275113 at main (53a866856e70). https://bugs.webkit.org/show_bug.cgi?id=269829

    Remove the owner element null check in WebFrame::parentFrame()
    https://bugs.webkit.org/show_bug.cgi?id=269829
    rdar://123343035

    Reviewed by Alex Christensen.

    I tried to fix a null pointer crash in 274274 at main with Site Isolation enabled but didn’t remove this
    null check. If the parent frame is being hosted in another process the owner element will always be null.

    * Source/WebKit/WebProcess/WebPage/WebFrame.cpp:
    (WebKit::WebFrame::parentFrame const):

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

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


  Commit: 3478c0c5b6423f73b6077330e83dcb212cf791d2
      https://github.com/WebKit/WebKit/commit/3478c0c5b6423f73b6077330e83dcb212cf791d2
  Author: Aditya Keerthi <akeerthi at apple.com>
  Date:   2024-04-28 (Sun, 28 Apr 2024)

  Changed paths:
    M Source/WebCore/dom/Document.cpp
    M Source/WebCore/dom/FullscreenManager.cpp
    M Source/WebCore/dom/FullscreenManager.h
    M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
    A Tools/TestWebKitAPI/Tests/ios/FullscreenLayoutParameters.mm
    R Tools/TestWebKitAPI/Tests/ios/FullscreenOverriddenLayoutParameters.mm

  Log Message:
  -----------
  Cherry-pick 275115 at main (e680442311f3). https://bugs.webkit.org/show_bug.cgi?id=269795

    REGRESSION: Scrolling down and attempting to fullscreen video on twitter.com displays the feed
    https://bugs.webkit.org/show_bug.cgi?id=269795
    rdar://122981183

    Reviewed by Jer Noble.

    In order for element fullscreen to behave correctly, sites rely on the following
    invariants:

    1. "fullscreenchange" is fired before "resize".
    2. The values of viewport properties during "fullscreenchange" match the fullscreen size.

    Twitter relies on (1), as they teardown the video player if "resize" occurs
    during the transition into fullscreen.

    270199 at main broke two things:

    1. The ordering of "fullscreenchange" and "resize" events when entering fullscreen on iPadOS.
    2. The values of viewport properties during the "fullscreenchange" event on visionOS.

    (1) went undetected for a long time, because at first, the effect was not this
    bug, but a crash, fixed in 273885 at main.

    272752 at main fixed (2), but also introduced (1) on visionOS.

    To the invariant mentioned above is true, fix by adding logic which ensures
    "resize" is dispatched after "fullscreenchange".

    * Source/WebCore/dom/Document.cpp:
    (WebCore::Document::setNeedsDOMWindowResizeEvent):
    (WebCore::Document::setNeedsVisualViewportResize):
    * Source/WebCore/dom/FullscreenManager.cpp:
    (WebCore::FullscreenManager::setAnimatingFullscreen):
    (WebCore::FullscreenManager::addPendingScheduledResize):
    * Source/WebCore/dom/FullscreenManager.h:
    * Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
    * Tools/TestWebKitAPI/Tests/ios/FullscreenLayoutParameters.mm: Renamed from Tools/TestWebKitAPI/Tests/ios/FullscreenOverriddenLayoutParameters.mm.
    (TestWebKitAPI::TEST):

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

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


  Commit: f65fd5872603c1efab80844827cd1fe6c5accaa5
      https://github.com/WebKit/WebKit/commit/f65fd5872603c1efab80844827cd1fe6c5accaa5
  Author: Rob Buis <rbuis at igalia.com>
  Date:   2024-04-28 (Sun, 28 Apr 2024)

  Changed paths:
    A LayoutTests/platform/glib/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt
    A LayoutTests/platform/ios/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt
    M LayoutTests/platform/mac-sonoma-wk2-lbse-text/TestExpectations
    A LayoutTests/platform/mac-sonoma-wk2-lbse-text/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt
    A LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.png
    A LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt
    A LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox.xhtml
    M Source/WebCore/rendering/RenderLayer.cpp
    M Source/WebCore/rendering/RenderLayer.h

  Log Message:
  -----------
  Cherry-pick 275117 at main (c443c971c715). https://bugs.webkit.org/show_bug.cgi?id=269234

    Fix custom/pattern-userSpaceOnUse-userToBaseTransform.xhtml
    https://bugs.webkit.org/show_bug.cgi?id=269234

    Reviewed by Nikolas Zimmermann.

    When determining RenderSVGRoot as root layer we also calculate
    any padding/border values as part of offsetFromAncestor, this
    means for patterns painting would be wrongly offset for pattern
    content. Instead, use the RenderSVGRoot, viewport as root layer
    which discards any border/padding for the pattern content painting.

    * LayoutTests/platform/glib/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt: Added.
    * LayoutTests/platform/ios/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt: Added.
    * LayoutTests/platform/mac-sonoma-wk2-lbse-text/TestExpectations:
    * LayoutTests/platform/mac-sonoma-wk2-lbse-text/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt: Added.
    * LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.png: Added.
    * LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt: Added.
    * LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox.xhtml: Added.
    * Source/WebCore/rendering/RenderLayer.cpp:
    (WebCore::RenderLayer::paintSVGResourceLayer):
    (WebCore::RenderLayer::enclosingSVGRootLayer const): Deleted.
    * Source/WebCore/rendering/RenderLayer.h:

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

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


  Commit: 61221113c277e7811d88a33237b5693cf21378fb
      https://github.com/WebKit/WebKit/commit/61221113c277e7811d88a33237b5693cf21378fb
  Author: Qianlang Chen <qianlangchen at apple.com>
  Date:   2024-04-28 (Sun, 28 Apr 2024)

  Changed paths:
    M Source/WebInspectorUI/UserInterface/Base/Main.js
    M Source/WebInspectorUI/UserInterface/Protocol/InspectorFrontendAPI.js
    M Source/WebInspectorUI/UserInterface/Views/LogContentView.js

  Log Message:
  -----------
  Cherry-pick 275143 at main (08a1f3998383). https://bugs.webkit.org/show_bug.cgi?id=268882

    Fix Web Inspector: Remember the message type selection in the Console tab
    rdar://122924275
    https://bugs.webkit.org/show_bug.cgi?id=268882

    Reviewed by Devin Rousso.

    When showing the the inspector's console using `WI.showConsole()`, the
    caller can optionally pass in a `requestedScope` to control which levels
    (AKA message types) to be filtered automatically when the Console tab
    shows up. However, when `requestedScope` is falsy or left empty, it
    always applies `WI.LogContentView.Scopes.All` instead, which
    overrides the levels selected by default, which are read from local
    settings when the scope bar is created at the inspector's startup.

    This commit removes the forced application of `Scopes.All`, so when
    `requestedScope` is left empty, the Console tab is shown with levels
    unchanged, which is the expected behavior when launching the Console tab
    through Develop -> Show JavaScript Console (or Option-Command-C).

    This fix has one known side-effect: when an inspector tab does not
    support split console view, pressing Esc will switch to the actual
    Console tab instead. (The Settings tab is one example of such tab.)
    This commit will make that also "remember" the previously selected
    levels instead of deselecting back to just `Scopes.All`, which is
    arguably the correct behavior anyway.

    This commit also cleans up on how `requestedScope` gets passed in;
    passing in as part of the `options` parameter allows callers of
    `showConsole()` to self-document the usage `requestedScope`.

    * Source/WebInspectorUI/UserInterface/Base/Main.js:
      - Fix the bug.
      - Adapt to the clean up for the `options` parameter.
    * Source/WebInspectorUI/UserInterface/Protocol/InspectorFrontendAPI.js:
    (InspectorFrontendAPI.showConsole):
      - Adapt to the clean up for the `options` parameter.
    * Source/WebInspectorUI/UserInterface/Views/LogContentView.js:
    (WI.LogContentView.prototype._showConsoleTab):
      - Adapt to the clean up for the `options` parameter.

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

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


  Commit: cef9106fb47d708920a30fe87c13033e8f483a28
      https://github.com/WebKit/WebKit/commit/cef9106fb47d708920a30fe87c13033e8f483a28
  Author: Ahmad Saleem <ahmad.saleem792+github at gmail.com>
  Date:   2024-04-28 (Sun, 28 Apr 2024)

  Changed paths:
    M Source/WebInspectorUI/UserInterface/Models/CSSKeywordCompletions.js

  Log Message:
  -----------
  Cherry-pick 275160 at main (d477c762a9ec). https://bugs.webkit.org/show_bug.cgi?id=269889

    Web Inspector: Add '*-conic-gradient' for autocompletion suggestion in 'background'

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

    Reviewed by Timothy Hatcher.

    This patch adds missing 'conic-gradient' and 'repeating-conic-gradient'
    support in autocompletion for background since these properties
    are supported as far back as 2018 with 204375 at main.

    * Source/WebInspectorUI/UserInterface/Models/CSSKeywordCompletions.js:
    (background): Add 'conic-gradient()' and 'repeating-conic-gradient()'

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

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


  Commit: 1a7ce9a4dd0bd2bab811a50f1cad907e71cb0c9c
      https://github.com/WebKit/WebKit/commit/1a7ce9a4dd0bd2bab811a50f1cad907e71cb0c9c
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-04-28 (Sun, 28 Apr 2024)

  Changed paths:
    M Source/WebCore/platform/mediastream/libwebrtc/gstreamer/RealtimeIncomingAudioSourceLibWebRTC.cpp

  Log Message:
  -----------
  Cherry-pick 275162 at main (429961d17d20). https://bugs.webkit.org/show_bug.cgi?id=269840

    [LibWebRTC][GStreamer] Incoming audio stream clips and glitches
    https://bugs.webkit.org/show_bug.cgi?id=269840

    Reviewed by Xabier Rodriguez-Calvar.

    Add audio meta to incoming audio buffers so that downstream converters don't produce garbage.

    * Source/WebCore/platform/mediastream/libwebrtc/gstreamer/RealtimeIncomingAudioSourceLibWebRTC.cpp:
    (WebCore::RealtimeIncomingAudioSourceLibWebRTC::OnData):

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

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


  Commit: 00bd6aeac161f301bfee3b6156aeb4ba7b72d006
      https://github.com/WebKit/WebKit/commit/00bd6aeac161f301bfee3b6156aeb4ba7b72d006
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-04-28 (Sun, 28 Apr 2024)

  Changed paths:
    M Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp

  Log Message:
  -----------
  Cherry-pick 275166 at main (764cbc51fef5). https://bugs.webkit.org/show_bug.cgi?id=269838

    [LibWebRTC][GStreamer] Incoming H.264 stream parsing fails
    https://bugs.webkit.org/show_bug.cgi?id=269838

    Reviewed by Xabier Rodriguez-Calvar.

    Workaround cases where the GStreamer LibWebRTC decoder is expected to process frames with invalid
    render time.

    * Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp:
    (WebCore::GStreamerVideoDecoder::GstDecoderFactory):

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

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


  Commit: c65b681ebb984c3f6799c550bd995989bed2d39d
      https://github.com/WebKit/WebKit/commit/c65b681ebb984c3f6799c550bd995989bed2d39d
  Author: Rob Buis <rbuis at igalia.com>
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
    A LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-expected.txt
    A LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-on-keydown-expected.txt
    A LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-on-keydown.html
    A LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options.html
    M Source/WebCore/html/DataListSuggestionInformation.h
    M Source/WebCore/html/HTMLDataListElement.cpp
    M Source/WebCore/html/HTMLDataListElement.h
    M Source/WebCore/html/TextFieldInputType.cpp
    M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
    M Source/WebKit/UIProcess/ios/WebDataListSuggestionsDropdownIOS.mm

  Log Message:
  -----------
  Cherry-pick 274608 at main (ba02cc6aade5). https://bugs.webkit.org/show_bug.cgi?id=201121

    Displayed datalist dropdown is out of sync with datalist options elements after DOM update
    https://bugs.webkit.org/show_bug.cgi?id=201121

    Reviewed by Aditya Keerthi.

    Adding datalist dropdown items by dynamically inserting options to the datalist on keydown/input change
    was not taking effect right away. To fix this, detect datalist DOM changes through HTMLDataListElement::childrenChanged
    and notify the corresponding input. This will eventually land in TextFieldInputType::dataListMayHaveChanged which
    now ends with trying to display the suggestions if the input is focused.

    Note that here a new DataListSuggestionActivationType value DataListMayHaveChanged is added to distinguish from
    current usages (text changed, indicator/control clicked).

    * LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-expected.txt: Added.
    * LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-on-keydown-expected.txt: Added.
    * LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-on-keydown.html: Added.
    * LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options.html: Added.
    * Source/WebCore/html/DataListSuggestionInformation.h:
    * Source/WebCore/html/HTMLDataListElement.cpp:
    (WebCore::HTMLDataListElement::childrenChanged):
    * Source/WebCore/html/HTMLDataListElement.h:
    * Source/WebCore/html/TextFieldInputType.cpp:
    (WebCore::TextFieldInputType::dataListMayHaveChanged):
    (WebCore::TextFieldInputType::displaySuggestions):
    * Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
    * Source/WebKit/UIProcess/ios/WebDataListSuggestionsDropdownIOS.mm:
    (-[WKDataListSuggestionsDropdown _displayWithActivationType:]):

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

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


  Commit: e8ae6ff45a705838ab002a7fc8829312ffc4e320
      https://github.com/WebKit/WebKit/commit/e8ae6ff45a705838ab002a7fc8829312ffc4e320
  Author: Ryosuke Niwa <rniwa at webkit.org>
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
    A LayoutTests/fast/dom/datalist-children-changed-crash-expected.txt
    A LayoutTests/fast/dom/datalist-children-changed-crash.html
    M Source/WebCore/dom/ContainerNode.cpp
    M Source/WebCore/html/HTMLDataListElement.cpp

  Log Message:
  -----------
  Cherry-pick 275221 at main (9a1d1c7db218). https://bugs.webkit.org/show_bug.cgi?id=269959

    HTMLDataListElement::childrenChanged doesn't call HTMLElement::childrenChanged
    https://bugs.webkit.org/show_bug.cgi?id=269959
    <rdar://123388053>

    Reviewed by Chris Dumez.

    This can lead to an inconsistent state in DOM so call that.

    * LayoutTests/fast/dom/datalist-children-changed-crash-expected.txt: Added.
    * LayoutTests/fast/dom/datalist-children-changed-crash.html: Added.
    * Source/WebCore/dom/ContainerNode.cpp:
    (WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Added a debug
    assertion to catch a similar mistake in the future.
    * Source/WebCore/html/HTMLDataListElement.cpp:
    (WebCore::HTMLDataListElement::childrenChanged):

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

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


  Commit: eef9441ffe42e5573ae7224e69d07deec66a301d
      https://github.com/WebKit/WebKit/commit/eef9441ffe42e5573ae7224e69d07deec66a301d
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
    M Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp
    M Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoFrameLibWebRTC.cpp
    M Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoFrameLibWebRTC.h

  Log Message:
  -----------
  Cherry-pick 275226 at main (277513e286a0). https://bugs.webkit.org/show_bug.cgi?id=269903

    [LibWebRTC][GStreamer] Clean-up GstSample ownership semantics in LibWebRTC VideoFrame
    https://bugs.webkit.org/show_bug.cgi?id=269903

    Reviewed by Xabier Rodriguez-Calvar.

    The sample reference can be moved to the VideoFrame.

    * Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp:
    (WebCore::GStreamerVideoDecoder::pullSample):
    * Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoFrameLibWebRTC.cpp:
    (WebCore::convertGStreamerSampleToLibWebRTCVideoFrame):
    (WebCore::GStreamerVideoFrameLibWebRTC::create):
    * Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoFrameLibWebRTC.h:
    (WebCore::GStreamerVideoFrameLibWebRTC::GStreamerVideoFrameLibWebRTC):

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

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


  Commit: cf8e66cdac79e66273712e88583669f6820ab9ae
      https://github.com/WebKit/WebKit/commit/cf8e66cdac79e66273712e88583669f6820ab9ae
  Author: Dana Estra <destra at apple.com>
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
    M Source/WebCore/Modules/modern-media-controls/controls/button.js

  Log Message:
  -----------
  Cherry-pick 275229 at main (c67d585912b3). https://bugs.webkit.org/show_bug.cgi?id=269951

    Pause control does not work in in-window mode
    https://bugs.webkit.org/show_bug.cgi?id=269951
    rdar://122834226

    Reviewed by Jer Noble.

    This bug was caused by both our event handler for clicking on the pause button
    and youtube's event handler for clicking on the video both being activated,
    causing the video to pause and then immediately be played again. To prevent
    this, in our button's event handler we now call stopPropagation().

    * Source/WebCore/Modules/modern-media-controls/controls/button.js:
    (Button.prototype.handleEvent):

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

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


  Commit: 72e431529386c9f361caf7f839d3e2d1a5f98aed
      https://github.com/WebKit/WebKit/commit/72e431529386c9f361caf7f839d3e2d1a5f98aed
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
    A LayoutTests/webaudio/getOutputTimestamp-expected.txt
    A LayoutTests/webaudio/getOutputTimestamp.html
    M Source/WebCore/platform/audio/AudioDestinationResampler.cpp

  Log Message:
  -----------
  Cherry-pick 275237 at main (33172dfe163a). https://bugs.webkit.org/show_bug.cgi?id=264247

    getOutputTimestamp() seems to use wrong time scale
    https://bugs.webkit.org/show_bug.cgi?id=264247
    rdar://118323705

    Reviewed by Eric Carlson.

    The time returned by getOutputTimestamp() was incorrectly divided by the
    sample rate. Fix this so the value returned is correct and matches Chrome
    and Firefox.

    * LayoutTests/webaudio/getOutputTimestamp-expected.txt: Added.
    * LayoutTests/webaudio/getOutputTimestamp.html: Added.
    * Source/WebCore/platform/audio/AudioDestinationResampler.cpp:
    (WebCore::AudioDestinationResampler::render):

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

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


  Commit: f923d49e0af5b52b335ff49d6701fcbcae464fb7
      https://github.com/WebKit/WebKit/commit/f923d49e0af5b52b335ff49d6701fcbcae464fb7
  Author: Sosuke Suzuki <sosuke.suzuki at dr-ubie.com>
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
    A JSTests/stress/string-replace-regexp-deopt-lastindex.js
    M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp

  Log Message:
  -----------
  Cherry-pick 275255 at main (3790f1e3cc0a). https://bugs.webkit.org/show_bug.cgi?id=246274

    [JSC] Don't optimize String.prototype.replace for RegExp searchValue with non-numeric lastIndex.
    https://bugs.webkit.org/show_bug.cgi?id=246274

    Reviewed by Alexey Shvayka.

    In DFGByteCodeParser, String.prototype.replace with a RegExp object as searchValue is inlined into a StringReplace node.
    So after DFG, lastIndex is no longer read and updated. Therefore, searchValue.lastIndex.toString is no longer invoked.
    This patch changes the code so that it doesn't inline if searchValue.lastIndex isn't numeric.

    https://tc39.es/ecma262/#sec-string.prototype.replace

    * JSTests/stress/string-replace-regexp-deopt-lastindex.js: Added.
    (shouldBe):
    (foo.regexLastIndex.toString):
    (foo):
    * Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
    (JSC::DFG::FixupPhase::addStringReplacePrimordialChecks):

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

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


  Commit: 45a128ec1c19b8994372a1abb5a5555a2043d470
      https://github.com/WebKit/WebKit/commit/45a128ec1c19b8994372a1abb5a5555a2043d470
  Author: Jean-Yves Avenard <jya at apple.com>
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
    A LayoutTests/media/media-source/media-managedmse-eviction-expected.txt
    A LayoutTests/media/media-source/media-managedmse-eviction.html
    M LayoutTests/platform/glib/TestExpectations
    M Source/WebCore/platform/graphics/SourceBufferPrivate.cpp

  Log Message:
  -----------
  Cherry-pick 275306 at main (19f884773fca). https://bugs.webkit.org/show_bug.cgi?id=270034

    [MSE] Media from the TimeRange containing currentTime can be evicted when it shouldn't
    https://bugs.webkit.org/show_bug.cgi?id=270034
    rdar://problem/123556056

    Reviewed by Eric Carlson.

    We want none of the data contiguous from the currentTime to the next discontinuity to be
    evicted to ensure continuous playback.
    This is inline with Google's proposal for having Eviction Policies.

    The comments in the eviction code indicated as such, but a logic error would have made
    the end of the current range be truncated if it was followed by another range
    after a discontinuity.

    * LayoutTests/media/media-source/media-managedmse-eviction-expected.txt: Added.
    * LayoutTests/media/media-source/media-managedmse-eviction.html: Added.
    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/platform/graphics/SourceBufferPrivate.cpp:
    (WebCore::SourceBufferPrivate::evictFrames):

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

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


  Commit: 5f382893b85e01690707fba11dd02878807725d8
      https://github.com/WebKit/WebKit/commit/5f382893b85e01690707fba11dd02878807725d8
  Author: Sihui Liu <sihui_liu at apple.com>
  Date:   2024-05-01 (Wed, 01 May 2024)

  Changed paths:
    M Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp

  Log Message:
  -----------
  Cherry-pick 275364 at main (fbc96c364894). https://bugs.webkit.org/show_bug.cgi?id=270137

    Add null check in SQLiteIDBBackingStore::getAllIndexRecords
    https://bugs.webkit.org/show_bug.cgi?id=270137
    rdar://113116109

    Reviewed by Chris Dumez.

    Crash traces indicate SQLiteIDBBackingStore may fail to find valid object store for requested operation, so return error
    instead of crashing network process in that case.

    * Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:
    (WebCore::IDBServer::SQLiteIDBBackingStore::getRecord):
    (WebCore::IDBServer::SQLiteIDBBackingStore::getAllObjectStoreRecords):
    (WebCore::IDBServer::SQLiteIDBBackingStore::getAllIndexRecords):

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

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


  Commit: fdf2beec03624c2101e4f89f8399ead9bfaf6c6c
      https://github.com/WebKit/WebKit/commit/fdf2beec03624c2101e4f89f8399ead9bfaf6c6c
  Author: Nicole Rosario <nicole_rosario at apple.com>
  Date:   2024-05-01 (Wed, 01 May 2024)

  Changed paths:
    A LayoutTests/ipc/send-ignored-network-message-expected.txt
    A LayoutTests/ipc/send-ignored-network-message.html
    M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp

  Log Message:
  -----------
  Cherry-pick 275369 at main (eaa2c46c3922). https://bugs.webkit.org/show_bug.cgi?id=270006

    ASSERT_WITH_SECURITY_IMPLICATION reached on Messages::NetworkProcess in NetworkConnectionToWebProcess::didReceiveMessage()
    https://bugs.webkit.org/show_bug.cgi?id=270006
    rdar://123087621

    Reviewed by Alex Christensen and Chris Dumez.

    Replace assertions checking that `decoder.messageReceiverName() !=
    Messages::NetworkProcess::messageReceiverName()` with MESSAGE_CHECK.
    Network messages from the web content process are safely ignored
    elsewhere already so the assert is not needed

    * Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
    (WebKit::NetworkConnectionToWebProcess::didReceiveMessage):
    (WebKit::NetworkConnectionToWebProcess::didReceiveSyncMessage):

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

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


  Commit: a5e0fc2f4bda568b4d61f95b7d0ff99cb9d61067
      https://github.com/WebKit/WebKit/commit/a5e0fc2f4bda568b4d61f95b7d0ff99cb9d61067
  Author: Rob Buis <rbuis at igalia.com>
  Date:   2024-05-01 (Wed, 01 May 2024)

  Changed paths:
    A LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-flex-fraction-expected.html
    A LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-flex-fraction.html
    M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
    M Source/WebCore/rendering/RenderGrid.h

  Log Message:
  -----------
  Cherry-pick 275376 at main (dd25a04355e3). https://bugs.webkit.org/show_bug.cgi?id=268874

    Regression (Safari 17 vs 16.5, 261003 at main): height collapsing on auto-height image when container-type set on parent
    https://bugs.webkit.org/show_bug.cgi?id=268874

    Reviewed by Alan Baradlay.

    In r261003 isComputingSizeOrInlineSizeContainment was used which did not consider grid track sizing direction. Fix that
    by using shouldCheckExplicitIntrinsicInnerLogicalSize which will take the direction into account.

    * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-flex-fraction-expected.html: Added.
    * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-flex-fraction.html: Added.
    * Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
    (WebCore::IndefiniteSizeStrategy::findUsedFlexFraction const):
    * Source/WebCore/rendering/RenderGrid.h:

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

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


  Commit: 6aa74dcba79d2629e5d65691759c31842a4ce09a
      https://github.com/WebKit/WebKit/commit/6aa74dcba79d2629e5d65691759c31842a4ce09a
  Author: Vivienne Watermeier <vwatermeier at igalia.com>
  Date:   2024-05-02 (Thu, 02 May 2024)

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

  Log Message:
  -----------
  Cherry-pick 275378 at main (877ae86c324a). https://bugs.webkit.org/show_bug.cgi?id=270100

    [GStreamer] Fix trimming of track IDs
    https://bugs.webkit.org/show_bug.cgi?id=270100

    Reviewed by Xabier Rodriguez-Calvar.

    Use StringView::find() to trim zeroes instead of ::trim(), to not remove
    trailing zeroes.

    See previous PR: https://github.com/WebKit/WebKit/pull/23668

    * Source/WebCore/platform/graphics/gstreamer/TrackPrivateBaseGStreamer.cpp:
    (WebCore::trimStreamId): fix implementation

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

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


  Commit: 962422e351686b79e5cfbd4e3adf20e292346189
      https://github.com/WebKit/WebKit/commit/962422e351686b79e5cfbd4e3adf20e292346189
  Author: Michael Saboff <msaboff at apple.com>
  Date:   2024-05-02 (Thu, 02 May 2024)

  Changed paths:
    M JSTests/stress/regexp-lookbehind.js
    M Source/JavaScriptCore/yarr/YarrInterpreter.cpp

  Log Message:
  -----------
  Cherry-pick 278204 at main (a330a52f59a8). https://bugs.webkit.org/show_bug.cgi?id=273426

    [JSC] ASSERTION FAILED: pos >= negativePositionOffest in char32_t JSC::Yarr::Interpreter<unsigned char>::InputStream::readChecked(unsigned int)
    https://bugs.webkit.org/show_bug.cgi?id=273426
    rdar://127013077

    Reviewed by Keith Miller.

    Added the same position version offest check to backtrackPatternCasedCharacter() that existed in backtrackPatternCharacter().
    Also fixed the restoration of the offest for a negative lookbehind assertion.

    Updated test.

    * JSTests/stress/regexp-lookbehind.js:
    * Source/JavaScriptCore/yarr/YarrInterpreter.cpp:
    (JSC::Yarr::Interpreter::backtrackPatternCasedCharacter):
    (JSC::Yarr::Interpreter::backtrackParentheticalAssertionBegin):

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

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


Compare: https://github.com/WebKit/WebKit/compare/4746fa7ce6f9...962422e35168

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