[webkit-changes] [WebKit/WebKit] aa7f18: Cherry-pick 260072 at main (0ba2b3fa758f). https://bu...

[Przemyslaw Gorszkowski]

  Branch: refs/heads/webkitglib/2.38
  Home:   https://github.com/WebKit/WebKit
  Commit: aa7f184e6a0dea1870478114d537862c191d6fca
      https://github.com/WebKit/WebKit/commit/aa7f184e6a0dea1870478114d537862c191d6fca
  Author: Arunsundar Kannan <arunsundar_kannan at apple.com>
  Date:   2023-02-12 (Sun, 12 Feb 2023)

  Changed paths:
    A LayoutTests/fast/html/parent-less-source-crash-type-change-expected.txt
    A LayoutTests/fast/html/parent-less-source-crash-type-change.html
    M Source/WebCore/html/HTMLSourceElement.cpp

  Log Message:
  -----------
  Cherry-pick 260072 at main (0ba2b3fa758f). https://bugs.webkit.org/show_bug.cgi?id=251888

    Attribute change results in assertion failure checking for parent node for a parent less element.
    https://bugs.webkit.org/show_bug.cgi?id=251888
    rdar://104819364

    Reviewed by Ryosuke Niwa.

    This change sets 'm_shouldCallSourcesChanged' to false after the parentNode is disassociated from the Node in question. This will avoid the call that leads to the crash.

    * LayoutTests/fast/html/parent-less-source-crash-type-change-expected.txt: Added.
    * LayoutTests/fast/html/parent-less-source-crash-type-change.html: Added.
    * Source/WebCore/dom/ContainerNodeAlgorithms.cpp:
    (WebCore::removeDetachedChildrenInContainer):
    * Source/WebCore/html/HTMLSourceElement.cpp:
    (WebCore::HTMLSourceElement::setShouldCallSourcesChanged):
    * Source/WebCore/html/HTMLSourceElement.h:

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


  Commit: 20c88c96ebc11c101bc3837870d58abdc862fb18
      https://github.com/WebKit/WebKit/commit/20c88c96ebc11c101bc3837870d58abdc862fb18
  Author: Andreu Botella <abotella at igalia.com>
  Date:   2023-02-12 (Sun, 12 Feb 2023)

  Changed paths:
    M LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-headers.any-expected.txt
    M LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-headers.any.js
    M LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-headers.any.worker-expected.txt
    M Source/WebCore/Modules/fetch/FetchHeaders.cpp

  Log Message:
  -----------
  Cherry-pick 260066 at main (2fbadf6b9f23). https://bugs.webkit.org/show_bug.cgi?id=251936

    Fix bug with empty header values in Headers objects with "request-no-cors" guard
    https://bugs.webkit.org/show_bug.cgi?id=251936

    Reviewed by Youenn Fablet.

    The `canWriteHeader` function in `FetchHeaders.cpp` checks whether a
    header name and value are valid for the guard of a Headers object.
    However, for the "request-no-cors" guard, this check only applies if the
    combined value of that header name is not the empty string.

    This check is not in the fetch specification, and seems to be there
    because such validation is skipped for the "request-no-cors" guard when
    deleting a header, and in the spec this validation happens as if the
    combined value was the empty string. However, WebKit's implementation
    does not currently use this method when removing headers, and as shown
    here, this extra condition allows setting headers when they should not
    be allowed.

    * LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-headers.any-expected.txt:
    * LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-headers.any.js:
    * LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-headers.any.serviceworker-expected.txt:
    * LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-headers.any.sharedworker-expected.txt:
    * LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-headers.any.worker-expected.txt:
    * Source/WebCore/Modules/fetch/FetchHeaders.cpp:
    (WebCore::canWriteHeader):

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


  Commit: b7c87101b105a99f5a26a45c795f83aa42416b0f
      https://github.com/WebKit/WebKit/commit/b7c87101b105a99f5a26a45c795f83aa42416b0f
  Author: Philippe Normand <philn at igalia.com>
  Date:   2023-02-12 (Sun, 12 Feb 2023)

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

  Log Message:
  -----------
  Cherry-pick 260082 at main (37a64834c957). https://bugs.webkit.org/show_bug.cgi?id=251913

    [GStreamer][MSE] Make the source element behave as an adaptive stream
    https://bugs.webkit.org/show_bug.cgi?id=251913

    Reviewed by Xabier Rodriguez-Calvar.

    Make the source element handle scheduling queries, similarly to the http source element. This
    allows urisourcebin to handle the source element as providing an "adaptive stream" and thus skip the
    internal multiqueue. Downstream decodebin already adds a multiqueue so this one is redundant. In
    order for this to work we also need to disable the "use-buffering" uridecodebin property.

    * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::configureElement):
    * Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
    (webKitMediaSrcQuery):
    (webkit_media_src_class_init):

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


  Commit: 4e4e9bf2e918416bcc2899dfb816874c1d0d7b4a
      https://github.com/WebKit/WebKit/commit/4e4e9bf2e918416bcc2899dfb816874c1d0d7b4a
  Author: Carlos Garcia Campos <cgarcia at igalia.com>
  Date:   2023-02-12 (Sun, 12 Feb 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/nicosia/NicosiaPaintingEngine.cpp

  Log Message:
  -----------
  Cherry-pick 260059 at main (4af5eb3490da). https://bugs.webkit.org/show_bug.cgi?id=251977

    [GTK4] Enable threaded rendering again using 1 painting thread by default
    https://bugs.webkit.org/show_bug.cgi?id=251977

    Reviewed by Žan Doberšek.

    It seems the issues with threaded rendering were actually caused by
    using multiple painting threads, but we can still use a single thread to
    move the painting off the main thread.

    * Source/WebCore/platform/graphics/nicosia/NicosiaPaintingEngine.cpp:
    (Nicosia::PaintingEngine::create):

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


  Commit: aa6ef50778e80c0d85c7bc2d269d9bb614020bde
      https://github.com/WebKit/WebKit/commit/aa6ef50778e80c0d85c7bc2d269d9bb614020bde
  Author: Przemyslaw Gorszkowski <pgorszkowski at igalia.com>
  Date:   2023-02-13 (Mon, 13 Feb 2023)

  Changed paths:
    M Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitFrame.cpp
    M Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitFramePrivate.h
    M Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp
    M Tools/TestWebKitAPI/Tests/WebKitGLib/WebExtensionTest.cpp

  Log Message:
  -----------
  Cherry-pick 259999 at main (4a9e02aa3418). https://bugs.webkit.org/show_bug.cgi?id=251256

    [GLIB] always update the active uri of the frame
    https://bugs.webkit.org/show_bug.cgi?id=251256

    Reviewed by Carlos Garcia Campos.

    It fixes the case when the uri has changed after first call of
    webkit_frame_get_uri and then webkit_frame_get_uri is called again.
    Without this fix the returned uri is the initial one not the actual one.

    Test: I modified existing caillback for uri change and add there additional
    asserts to test added functionality.

    * Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitFrame.cpp:
    (webkitFrameSetUri):
    (webkit_frame_get_uri):
    * Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitFramePrivate.h:
    * Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebPage.cpp:
    * Tools/TestWebKitAPI/Tests/WebKitGLib/WebExtensionTest.cpp:
    (uriChangedCallback):

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


Compare: https://github.com/WebKit/WebKit/compare/2db33e3a4790...aa6ef50778e8