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_...@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@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 <timo...@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@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 <eoca...@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@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 <eoca...@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@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_mutav...@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
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
