[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