[webkit-changes] [WebKit/WebKit] 0fc290: Cherry-pick 259966 at main (7833f1f216eb). https://bu...

Enrique Ocaña González noreply at github.com
Sun Feb 12 07:38:25 PST 2023


  Branch: refs/heads/webkitglib/2.38
  Home:   https://github.com/WebKit/WebKit
  Commit: 0fc290b556ba5b37658cf7e346e9d22a56147872
      https://github.com/WebKit/WebKit/commit/0fc290b556ba5b37658cf7e346e9d22a56147872
  Author: Sihui Liu <sihui_liu at apple.com>
  Date:   2023-02-12 (Sun, 12 Feb 2023)

  Changed paths:
    M Source/WebCore/platform/sql/SQLiteTransaction.h
    M Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp

  Log Message:
  -----------
  Cherry-pick 259966 at main (7833f1f216eb). https://bugs.webkit.org/show_bug.cgi?id=251764

    SQLiteStorageArea should start new transaction when the previous one is rolled back by sqlite
    https://bugs.webkit.org/show_bug.cgi?id=251764
    rdar://105061923

    Reviewed by Chris Dumez.

    When debugging storage_local_setitem_quotaexceedederr.window.html failure, I found SQLiteStorageArea does not start new
    transaction after SQLITE_FULL error, which means it would create an implicit transaction for each statement. To fix
    this, this patch makes startTransactionIfNecessary() check whether existing transaction is already rolled back. If the
    transaction is rolled back, it should start a new transaction.

    * Source/WebCore/platform/sql/SQLiteTransaction.h:
    * Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp:
    (WebKit::SQLiteStorageArea::startTransactionIfNecessary):

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


  Commit: 3ee2ec266fad0f7180a2f9b51147f19a709ff6b9
      https://github.com/WebKit/WebKit/commit/3ee2ec266fad0f7180a2f9b51147f19a709ff6b9
  Author: Timothy Hatcher <timothy at apple.com>
  Date:   2023-02-12 (Sun, 12 Feb 2023)

  Changed paths:
    M Source/WebKit/NetworkProcess/NetworkProcess.cpp
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm

  Log Message:
  -----------
  Cherry-pick 259976 at main (d8706351a89a). https://webkit.org/b/251858

    Cross-Origin-Resource-Policy blocks fetch from extensions.
    https://webkit.org/b/251858
    rdar://103793194

    Reviewed by Chris Dumez.

    SecurityPolicy was blocking the fetch load due to the Cross-Origin-Resource-Policy check
    in the NetworkProcess. In the WebProcess, SecurityPolicy checks were succeeding due to the
    existing call to SecurityPolicy::allowAccessTo() when parsing the corsDisablingPatterns.
    This step was missing in the NetworkProcess. Now both processes have the same checks.

    * Source/WebKit/NetworkProcess/NetworkProcess.cpp:
    (WebKit::NetworkProcess::setCORSDisablingPatterns): Add the pattern to SecurityPolicy to
    match WebPage.cpp's parseAndAllowAccessToCORSDisablingPatterns().
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm:
    (TEST(URLSchemeHandler, DisableCORSAndCORP)): Added.

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


  Commit: 665eea28143bc8461d72025bcaad0446cd300e96
      https://github.com/WebKit/WebKit/commit/665eea28143bc8461d72025bcaad0446cd300e96
  Author: Enrique Ocaña González <eocanha at igalia.com>
  Date:   2023-02-12 (Sun, 12 Feb 2023)

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

  Log Message:
  -----------
  Cherry-pick 260003 at main (ce7515d38a3c). https://bugs.webkit.org/show_bug.cgi?id=251866

    [MSE][GStreamer] Use mse-bytestream variant on appends
    https://bugs.webkit.org/show_bug.cgi?id=251866

    GStreamer Merge Request https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3867
    added improved MSE support in qtdemux, fixing a buffer clipping issue. For these changes to have
    effect, WebKit needs to use "variant: mse-bytestream" in the caps when supplying buffers to the
    AppendPipeline.

    Note that using this new variant has no negative/positive effect on GStreamer versions that still
    don't include the qtdemux fix.

    Reviewed by Alicia Boya Garcia.

    * Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:
    (WebCore::AppendPipeline::AppendPipeline): Use variant: mse-bytestream for qtdemux.

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


  Commit: 2db33e3a47908d20f3ded500b22d46646a5ef62e
      https://github.com/WebKit/WebKit/commit/2db33e3a47908d20f3ded500b22d46646a5ef62e
  Author: Enrique Ocaña González <eocanha at igalia.com>
  Date:   2023-02-12 (Sun, 12 Feb 2023)

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

  Log Message:
  -----------
  Cherry-pick 260004 at main (fa12275b80a8). https://bugs.webkit.org/show_bug.cgi?id=251868

    [MSE][GStreamer] Don't extend PTS of non-key frame
    https://bugs.webkit.org/show_bug.cgi?id=251868

    The edit list support patch from
    https://bugs.webkit.org/show_bug.cgi?id=231019 was reverted in
    https://bugs.webkit.org/show_bug.cgi?id=244428. While that patch isn't
    landed again, we're growing the first buffer of an append near the
    begining of the stream to make it start from 0. This workaround uses a
    tolerance of 0.1s, and can cause problems on frames short enough to fit
    more than one time in the tolerance margin (eg: 3 frames at 30fps would
    fit, as well as 6 frames at 60fps).

    The process of growing the seconde frame that still fit in the tolerance
    is triggering the deletion of the first frame, which is usually a sync
    one. This sweeps other frames into the deletion and causes problems.

    This patch changes the condition to enable frame growing to only apply
    on key frames (sync samples).

    Original author: Eugene Mutavchi <Ievgen_Mutavchi at comcast.com>
    See: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1015

    Reviewed by Alicia Boya Garcia.

    * Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:
    (WebCore::AppendPipeline::appsinkNewSample): Don't extend PTS of non-key frame.

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


Compare: https://github.com/WebKit/WebKit/compare/4c25e39c993c...2db33e3a4790


More information about the webkit-changes mailing list