[webkit-changes] [WebKit/WebKit] f387c2: Cherry-pick 260860 at main (e9dd88dee673). https://bu...

[Patrick]

  Branch: refs/heads/webkitglib/2.38
  Home:   https://github.com/WebKit/WebKit
  Commit: f387c2f168e6902617dd1de91f2d4bc75ac4ccb6
      https://github.com/WebKit/WebKit/commit/f387c2f168e6902617dd1de91f2d4bc75ac4ccb6
  Author: Charlie Wolfe <charliew at apple.com>
  Date:   2023-03-05 (Sun, 05 Mar 2023)

  Changed paths:
    A LayoutTests/http/tests/navigation/cross-origin-iframe-location-hash-reexecute-onload-expected.txt
    A LayoutTests/http/tests/navigation/cross-origin-iframe-location-hash-reexecute-onload.html
    A LayoutTests/http/tests/navigation/resources/change-location-hash-onload.html
    M Source/WebCore/loader/FrameLoader.cpp

  Log Message:
  -----------
  Cherry-pick 260860 at main (e9dd88dee673). https://bugs.webkit.org/show_bug.cgi?id=252931

    window.onload is repeatedly re-executed when changing URL fragment during onload
    https://bugs.webkit.org/show_bug.cgi?id=252931
    rdar://105158419

    Reviewed by Chris Dumez.

    When a cross-origin iframe changes its fragment identifier while its load event is being processed,
    we end up in a state where we will continually re-fire window.onload. We should fix this by only
    firing the load event on the frame's owner element. This still addresses the concern the original
    change fixed (259384 at main), but without needing to always re-fire the window load event.

    * LayoutTests/http/tests/navigation/cross-origin-iframe-location-hash-reexecute-onload-expected.txt: Added.
    * LayoutTests/http/tests/navigation/cross-origin-iframe-location-hash-reexecute-onload.html: Added.
    * LayoutTests/http/tests/navigation/resources/change-location-hash-onload.html: Added.
    * Source/WebCore/loader/FrameLoader.cpp:
    (WebCore::FrameLoader::loadInSameDocument):

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


  Commit: b30ff7c04c38edddf1a838b6933c926a2c466cc3
      https://github.com/WebKit/WebKit/commit/b30ff7c04c38edddf1a838b6933c926a2c466cc3
  Author: Žan Doberšek <zdobersek at igalia.com>
  Date:   2023-03-05 (Sun, 05 Mar 2023)

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

  Log Message:
  -----------
  Cherry-pick 261072 at main (5c473b4124bf). https://bugs.webkit.org/show_bug.cgi?id=253244

    [GStreamer] Establish locking when mapping gbm_bo objects for software-decoded data upload
    https://bugs.webkit.org/show_bug.cgi?id=253244

    Reviewed by Philippe Normand.

    When separate GStreamer pipelines are established for different video elements,
    mapping the gbm_bo objects in parallel across different threads can lead to
    crashes and GPU memory corruption.

    The different gbm_bo objects originate from a single gbm_device, which is fine.
    Spawning gbm_bo objects and retrieving different attributes from them isn't
    showing as problematic, but libgbm thread safety guarantees still need research.

    Mapping gbm_bo objects in parallel is proving as problematic, and the length of
    the upload of software-decoded data into the mapped memory regions takes long
    enough for these problems to inhibit stability. To avoid that, a global lock is
    provided on the gbm_bo-mapping Destination class inside the
    MediaPlayerPrivateGStreamer::pushDMABufToCompositor() method. This lock is
    activated whenever data for a given plane is moved over from the GStreamer-based
    software decoder into the gbm_bo object.

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

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


  Commit: f832b533ef178df4e2055f394118ca162a59170c
      https://github.com/WebKit/WebKit/commit/f832b533ef178df4e2055f394118ca162a59170c
  Author: Žan Doberšek <zdobersek at igalia.com>
  Date:   2023-03-05 (Sun, 05 Mar 2023)

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

  Log Message:
  -----------
  Cherry-pick 261077 at main (9b1c8b87c0a4). https://bugs.webkit.org/show_bug.cgi?id=253245

    [GStreamer] Improve GBM swapchain buffer handling
    https://bugs.webkit.org/show_bug.cgi?id=253245

    Reviewed by Philippe Normand.

    In MediaPlayerPrivateGStreamer::pushDMABufToCompositor(), when allocating
    buffer objects from the GBMBufferSwapchain to upload the software-decoded
    video data, do a null check on the retrieved buffer. This avoids proceeding with
    a null object that would be returned when for whatever perverse reason the
    swapchain is drained of available buffers.

    One such reason is when allocating, retrieving and locking buffers from the
    swapchain under an inactive proxy. In that case, the buffer doesn't end up
    being pushed into the composition, and it's then also never released and made
    available for reuse, effectively draining the swapchain.

    This case is avoidable through earlier detection of an inactive proxy. The proxy
    lock and is-active check are unified between different codepaths and done before
    deciding which codepath is taken.

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

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


  Commit: 1dd62a29b52f009da1813fbe45dfbc9b879481c5
      https://github.com/WebKit/WebKit/commit/1dd62a29b52f009da1813fbe45dfbc9b879481c5
  Author: Brian Weinstein <bweinstein at apple.com>
  Date:   2023-03-05 (Sun, 05 Mar 2023)

  Changed paths:
    M LayoutTests/http/tests/contentextensions/css-display-none.html
    M LayoutTests/http/tests/contentextensions/css-display-none.html.json
    M Source/WebCore/contentextensions/ContentExtension.cpp
    M Source/WebCore/contentextensions/ContentExtensionParser.cpp
    M Source/WebCore/contentextensions/ContentExtensionParser.h
    M Source/WebCore/contentextensions/ContentExtensionStyleSheet.cpp
    M Tools/TestWebKitAPI/Tests/WebCore/ContentExtensions.cpp

  Log Message:
  -----------
  Cherry-pick 259068 at main (355ce06ba535). https://bugs.webkit.org/show_bug.cgi?id=250609

    Safari Content Blocker doesn't support :has() selector
    https://bugs.webkit.org/show_bug.cgi?id=250609
    rdar://103976010

    Reviewed by Antti Koivisto and Alex Christensen.

    When creating the CSSParsers for content blocker parsing and compilation, make sure to opt
    into hasPseudoClassEnabled so selectors like :has work. The places this was needed were:
    - ContentExtensionParser (for parsing the rules)
    - ContentExtension (for the global display none rules)
    - ContentExtensionStyleSheet (for the other display none rules)

    Also update the contentextensions css-display-none test to test this functionality.

    * Source/WebCore/contentextensions/ContentExtension.cpp:
    (WebCore::ContentExtensions::ContentExtension::compileGlobalDisplayNoneStyleSheet):
    * Source/WebCore/contentextensions/ContentExtensionParser.cpp:
    (WebCore::ContentExtensions::isValidCSSSelector):

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


  Commit: a334683ab68e4ea4df960843a310979a98a6c63b
      https://github.com/WebKit/WebKit/commit/a334683ab68e4ea4df960843a310979a98a6c63b
  Author: Brian Weinstein <bweinstein at apple.com>
  Date:   2023-03-05 (Sun, 05 Mar 2023)

  Changed paths:
    M LayoutTests/http/tests/contentextensions/css-display-none.html
    M LayoutTests/http/tests/contentextensions/css-display-none.html.json
    M Source/WebCore/contentextensions/ContentExtensionParser.cpp

  Log Message:
  -----------
  Cherry-pick 260638 at main (6f913a33098b). https://bugs.webkit.org/show_bug.cgi?id=252677

    Content Blocker API ignores some CSS Selectors with uppercase letters.
    https://bugs.webkit.org/show_bug.cgi?id=252677
    rdar://105648971

    Reviewed by Antti Koivisto.

    The fix for https://bugs.webkit.org/show_bug.cgi?id=250609 caused us to use Quirks mode when both
    parsing content blocker rules and applying them.

    That caused this regression, since rules like .SomeCLass stopped working in Quirks mode.

    To fix this, make us use Quirks mode when actually parsing the rules, but standard mode when
    applying them, to match how the behavior was before https://bugs.webkit.org/show_bug.cgi?id=250609.

    * LayoutTests/http/tests/contentextensions/css-display-none.html:
    * LayoutTests/http/tests/contentextensions/css-display-none.html.json:
    * Source/WebCore/contentextensions/ContentExtensionParser.cpp:
    (WebCore::ContentExtensions::isValidCSSSelector):
    (WebCore::ContentExtensions::contentExtensionCSSParserContext):

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


  Commit: 53eccce198cbcef6fdc29316456356d3323db2d8
      https://github.com/WebKit/WebKit/commit/53eccce198cbcef6fdc29316456356d3323db2d8
  Author: Patrick Griffis <pgriffis at igalia.com>
  Date:   2023-03-05 (Sun, 05 Mar 2023)

  Changed paths:
    M Source/WebCore/Modules/mediastream/gstreamer/GStreamerDataChannelHandler.cpp

  Log Message:
  -----------
  Cherry-pick 260580 at main (70ed120ac0ba). https://bugs.webkit.org/show_bug.cgi?id=252601

    [GStreamer] GST_WEBRTC_DATA_CHANNEL_STATE_NEW was removed in 1.21.1
    https://bugs.webkit.org/show_bug.cgi?id=252601

    Reviewed by Philippe Normand.

    * Source/WebCore/Modules/mediastream/gstreamer/GStreamerDataChannelHandler.cpp:
    (WebCore::GStreamerDataChannelHandler::checkState):

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


Compare: https://github.com/WebKit/WebKit/compare/f0479f9c7c45...53eccce198cb