Branch: refs/heads/webkitglib/2.38
Home: https://github.com/WebKit/WebKit
Commit: b175d42c8705e42d31f8215352386f1d271ac398
https://github.com/WebKit/WebKit/commit/b175d42c8705e42d31f8215352386f1d271ac398
Author: Žan Doberšek <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in
M Source/WebKit/NetworkProcess/NetworkProcess.messages.in
Log Message:
-----------
Cherry-pick 256645@main (dc1660b2260a).
https://bugs.webkit.org/show_bug.cgi?id=247881
[WK2] std::optional<WebKit::NavigatingToAppBoundDomain> parameters
shouldn't be marked as enums in IPC messages
https://bugs.webkit.org/show_bug.cgi?id=247881
Reviewed by Kimmo Kinnunen.
The NavigatingToAppBoundDomain enum values wrapped in std::optional<> in
various IPC messages shouldn't
be marked as enums. The enumeration values are handled appropriately during
encoding and decoding of
std::optional<>, whereas the additional marking hampers generation of a
reference type as the parameter
type for each affected message.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* Source/WebKit/NetworkProcess/NetworkProcess.messages.in:
Canonical link: https://commits.webkit.org/256645@main
Commit: 6b0cd5308aed0ef45a4b970e0788d557020dcf09
https://github.com/WebKit/WebKit/commit/6b0cd5308aed0ef45a4b970e0788d557020dcf09
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/platform/GStreamer.cmake
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
A Source/WebCore/platform/gstreamer/GStreamerCodecUtilities.cpp
A Source/WebCore/platform/gstreamer/GStreamerCodecUtilities.h
Log Message:
-----------
Cherry-pick 257615@main (cf92dc1de95a).
https://bugs.webkit.org/show_bug.cgi?id=248948
[GStreamer] Minimal codec parsing module
https://bugs.webkit.org/show_bug.cgi?id=248948
Reviewed by Xabier Rodriguez-Calvar.
This patch exposes API for parsing H.264 profile and level from a codec
string, this code existed in
the registry scanner before but can now be reused for eg. the upcoming
WebCodecs backend. A minimal
VP9 profile parsing utility is also part of this patch.
The new file is stored in platform/gstreamer, we should gradually add new
GStreamer modules there
when appropriate. Some of the platform/graphics/gstreamer files could also
move there at some point.
* Source/WebCore/platform/GStreamer.cmake:
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
(WebCore::GStreamerRegistryScanner::isAVC1CodecSupported const):
* Source/WebCore/platform/gstreamer/GStreamerCodecUtilities.cpp: Added.
(WebCore::ensureDebugCategoryInitialized):
(WebCore::GStreamerCodecUtilities::parseVP9Profile):
* Source/WebCore/platform/gstreamer/GStreamerCodecUtilities.h: Added.
Canonical link: https://commits.webkit.org/257615@main
Commit: 899597131791c72d4b70aad916f4292d45379ac5
https://github.com/WebKit/WebKit/commit/899597131791c72d4b70aad916f4292d45379ac5
Author: Ryosuke Niwa <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
A
LayoutTests/editing/pasteboard/copy-content-with-display-none-exiting-ancestors-expected.txt
A
LayoutTests/editing/pasteboard/copy-content-with-display-none-exiting-ancestors.html
M Source/WebCore/editing/markup.cpp
Log Message:
-----------
Cherry-pick 257977@main (24540c7a6767).
https://bugs.webkit.org/show_bug.cgi?id=249426
REGRESSION(205039@main): StyledMarkupAccumulator sometimes does not emit an
end tag
https://bugs.webkit.org/show_bug.cgi?id=249426
Reviewed by Wenson Hsieh.
The bug was caused by traverseNodesForSerialization failing to register
ancestors that climbed out of
when enterNode returns false. Fixed the bug by re-using the normal
traversal code.
*
LayoutTests/editing/pasteboard/copy-content-with-display-none-exiting-ancestors-expected.txt:
Added.
*
LayoutTests/editing/pasteboard/copy-content-with-display-none-exiting-ancestors.html:
Added.
* Source/WebCore/editing/markup.cpp:
(WebCore::StyledMarkupAccumulator::traverseNodesForSerialization):
Canonical link: https://commits.webkit.org/257977@main
Commit: 7e09144be0c1332cbbcddec51527be676fe060d9
https://github.com/WebKit/WebKit/commit/7e09144be0c1332cbbcddec51527be676fe060d9
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp
Log Message:
-----------
Cherry-pick 258044@main (c75026b5ef15).
https://bugs.webkit.org/show_bug.cgi?id=248742
[GStreamer][MSE] Refactor demuxer handling in AppendPipeline
https://bugs.webkit.org/show_bug.cgi?id=248742
Reviewed by Alicia Boya Garcia.
Instead of a boolean `hasDemuxer` we can check the element metadata for the
`Demuxer` classifier.
* Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:
(WebCore::AppendPipeline::AppendPipeline):
Canonical link: https://commits.webkit.org/258044@main
Commit: 8a3d28c205e8fd08284625901e0054f1a2e4874a
https://github.com/WebKit/WebKit/commit/8a3d28c205e8fd08284625901e0054f1a2e4874a
Author: Ryan Reno <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/page/csp/ContentSecurityPolicyDirectiveList.cpp
Log Message:
-----------
Cherry-pick 258110@main (0445ac553799).
https://bugs.webkit.org/show_bug.cgi?id=249596
Store CSP delivered via meta tag as a valid HTTP header.
https://bugs.webkit.org/show_bug.cgi?id=249596
rdar://103170891
Reviewed by Brent Fulgham.
A CSP delivered via a meta tag could have invalid HTTP header values in it.
Take for example this:
<meta http-equiv="Content-Security-Policy" content="
default-src 'none';
script-src 'self';
img-src 'self'">
The value of the CSP header that the ContentSecurityPolicyDirectiveList
will get will be the raw
string including whitespace and most importantly newline characters. These
newline characters are
invalid characters in an HTTP header[0].
The parsing algorithm for CSP handles this appropriately and creates a
valid CSP for the document. However,
if a script in the document then creates blob URLs which are navigated to
or otherwise fetched, the Network
process will return a ResourceResponse object with a
Content-Security-Policy header that contains the newlines.
This is caught by the ResourceResponseBase::containsInvalidHTTPHeaders
function which causes the fetch to fail.
To combat this we can simply strip the newline characters from the
meta-delivered CSP and store the policy as a
valid HTTP header.
[0] https://fetch.spec.whatwg.org/#header-value
* Source/WebCore/page/csp/ContentSecurityPolicyDirectiveList.cpp:
(WebCore::ContentSecurityPolicyDirectiveList::parse):
Canonical link: https://commits.webkit.org/258110@main
Commit: e81cf7ef608b4a33039fc70e29fcada634694d7d
https://github.com/WebKit/WebKit/commit/e81cf7ef608b4a33039fc70e29fcada634694d7d
Author: Carlos Garcia Campos <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
A
LayoutTests/http/tests/security/contentSecurityPolicy/blob-url-invalid-http-header-expected.txt
A
LayoutTests/http/tests/security/contentSecurityPolicy/blob-url-invalid-http-header.html
M Source/WebCore/page/csp/ContentSecurityPolicy.cpp
Log Message:
-----------
Cherry-pick 258130@main (d89d47f7fd45).
https://bugs.webkit.org/show_bug.cgi?id=249213
Images are not loaded in element application
https://bugs.webkit.org/show_bug.cgi?id=249213
Reviewed by Xabier Rodriguez-Calvar.
Element application uses the fetch api to download images and convert
them to a blob that is then requested. The problem is that the blob
request is failing due to invalid HTTP header in response. The invalid
header is Content-Security-Policy that is generated by the blob loader
using the security context policy. The document policy comes from
http-equiv meta and contains newlines, which are allowed there, but
invalid for an HTTP header value.
Test:
http/tests/security/contentSecurityPolicy/blob-url-invalid-http-header.html
*
LayoutTests/http/tests/security/contentSecurityPolicy/blob-url-invalid-http-header-expected.txt:
Added.
*
LayoutTests/http/tests/security/contentSecurityPolicy/blob-url-invalid-http-header.html:
Added.
* Source/WebCore/page/csp/ContentSecurityPolicy.cpp:
(WebCore::ContentSecurityPolicy::responseHeaders const): Make the http
header value valid if needed.
Canonical link: https://commits.webkit.org/258130@main
Commit: a644f5d738edd81df62337c92621bec9fa2c7278
https://github.com/WebKit/WebKit/commit/a644f5d738edd81df62337c92621bec9fa2c7278
Author: Ahmad Saleem <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
A LayoutTests/fast/table/table-overflow-crash-expected.txt
A LayoutTests/fast/table/table-overflow-crash.html
M Source/WebCore/rendering/RenderTable.cpp
Log Message:
-----------
Cherry-pick 258227@main (0a821c7d68ea).
https://bugs.webkit.org/show_bug.cgi?id=249707
Make sure rows are updated during simplified layout
https://bugs.webkit.org/show_bug.cgi?id=249707
Reviewed by Alan Baradlay.
Merge - https://src.chromium.org/viewvc/blink?revision=191146&view=revision
When we are calling RenderTable::simplifiedNormalFlowLayout(), we have to
make sure that we call section->layoutRows() before we do the
section->computeOverflowFromCells(). The call to layoutRows is needed
because
it will reset and update the m_forceSlowPaintPathWithOverflowingCell
flag which causes to fail the ASSERT.
* Source/WebCore/rendering/RenderTable.cpp:
(RenderTable::simplifiedNormalFlowLayout): Add "layoutRows" before
"computeOverflowFromCells"
* LayoutTests/fast/table/table-overflow-crash.html: Add Test Case
* LayoutTests/fast/table/table-overflow-crash-expected.txt: Add Test Case
Expectation
Canonical link: https://commits.webkit.org/258227@main
Commit: b12785ba05a00d04734a1e0091553459cfa9eaae
https://github.com/WebKit/WebKit/commit/b12785ba05a00d04734a1e0091553459cfa9eaae
Author: Ahmad Saleem <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
A
LayoutTests/fast/multicol/unbreakable-content-taller-than-height-crash-expected.txt
A
LayoutTests/fast/multicol/unbreakable-content-taller-than-height-crash.html
M Source/WebCore/rendering/RenderMultiColumnSet.cpp
Log Message:
-----------
Cherry-pick 258230@main (3edf242b588b).
https://bugs.webkit.org/show_bug.cgi?id=249705
Give up on stretching columns if they have already reached max height
https://bugs.webkit.org/show_bug.cgi?id=249705
Reviewed by Alan Baradlay.
Merge - https://src.chromium.org/viewvc/blink?view=revision&revision=192636
This doesn't change any behavior (column heights were already clamped
against
max height), but it avoids an assertion failure that would occur if no space
shortage is recorded during a render pass. Unbreakable content (lines)
that's
taller than the column (max) height don't record space shortage, as columns
cannot be stretched beyond the (max) height anyway.
* Source/WebCore/rendering/RenderMultiColumnSet.cpp:
(RenderMultiColumnSet::calculateBalancedHeight): Add if condition to
restrict column height
*
LayoutTests/fast/multicol/unbreakable-content-taller-than-height-crash.html:
Add Test Case
*
LayoutTests/fast/multicol/unbreakable-content-taller-than-height-crash-expected.txt:
Add Test Case Expectation
Canonical link: https://commits.webkit.org/258230@main
Commit: b13c06e8117ddc935764a0f70bb68b6bbdf6c03d
https://github.com/WebKit/WebKit/commit/b13c06e8117ddc935764a0f70bb68b6bbdf6c03d
Author: Michael Catanzaro <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WTF/wtf/PlatformHave.h
M Source/WebKit/UIProcess/Notifications/glib/NotificationService.cpp
Log Message:
-----------
Cherry-pick 258260@main (1446ba237462).
https://bugs.webkit.org/show_bug.cgi?id=248727
gdesktopappinfo.h not excluded on macOS
https://bugs.webkit.org/show_bug.cgi?id=248727
Reviewed by Carlos Garcia Campos.
Although macOS has most of the gio-unix-2.0 functionality, this
particular header is an exception and just needs to be handled
specially.
MacPorts has a patch to sometimes build with GDesktopAppInfo enabled, so
it's best to just detect the presence of the header instead of trying to
enable this code on OS(UNIX_BUT_NOT_MACOS_EXCEPT_SOMETIMES).
* Source/WTF/wtf/PlatformHave.h:
* Source/WebKit/UIProcess/Notifications/glib/NotificationService.cpp:
(WebKit::applicationIcon):
Canonical link: https://commits.webkit.org/258260@main
Commit: fc67c8179b486563cdabf294ec8856f8c46e4d0b
https://github.com/WebKit/WebKit/commit/fc67c8179b486563cdabf294ec8856f8c46e4d0b
Author: Alex Christensen <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/workers/service/server/RegistrationDatabase.cpp
M Source/WebCore/workers/service/server/RegistrationDatabase.h
M Source/WebCore/workers/service/server/RegistrationStore.cpp
M Source/WebCore/workers/service/server/RegistrationStore.h
M Source/WebCore/workers/service/server/SWServer.cpp
M Source/WebCore/workers/service/server/SWServer.h
Log Message:
-----------
Cherry-pick 258268@main (5ea941c44c07).
https://bugs.webkit.org/show_bug.cgi?id=249723
REGRESSION (258175@main?): [ iOS Debug ]
TestWebKitAPI.InAppBrowserPrivacy.AppBoundDomainAllowsServiceWorkers is a
consistent failure
https://bugs.webkit.org/show_bug.cgi?id=249723
<rdar://problem/103601970>
Reviewed by Brady Eidson.
There was a race condition because we were assuming that
SWServer::addRegistrationFromStore always completes immediately.
This is true most of the time, except during process startup. So if we
remove all service worker registrations as the first
thing we do with a network process, sometimes we would see a call to
SWServer::addRegistration after we thought we had completed
removing all the service worker registrations, but only if
m_hasReceivedAppBoundDomains is false. This was seen by the API
test TestWebKitAPI.InAppBrowserPrivacy.AppBoundDomainAllowsServiceWorkers
running after a test that left a service worker
registration on the disk.
* Source/WebCore/workers/service/server/RegistrationDatabase.cpp:
(WebCore::RegistrationDatabase::openSQLiteDatabase):
(WebCore::RegistrationDatabase::importRecordsIfNecessary):
(WebCore::RegistrationDatabase::schedulePushChanges):
(WebCore::RegistrationDatabase::doPushChanges):
(WebCore::RegistrationDatabase::doPushChangesWithOpenDatabase):
(WebCore::RegistrationDatabase::importRecords):
(WebCore::RegistrationDatabase::addRegistrationToStore):
(WebCore::RegistrationDatabase::databaseFailedToOpen):
(WebCore::RegistrationDatabase::databaseOpenedAndRecordsImported):
* Source/WebCore/workers/service/server/RegistrationDatabase.h:
* Source/WebCore/workers/service/server/RegistrationStore.cpp:
(WebCore::RegistrationStore::addRegistrationFromDatabase):
* Source/WebCore/workers/service/server/RegistrationStore.h:
* Source/WebCore/workers/service/server/SWServer.cpp:
(WebCore::SWServer::addRegistrationFromStore):
* Source/WebCore/workers/service/server/SWServer.h:
Canonical link: https://commits.webkit.org/258268@main
Commit: 7335952db75f79f3b6d9a59eed4ffcd5546e0704
https://github.com/WebKit/WebKit/commit/7335952db75f79f3b6d9a59eed4ffcd5546e0704
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.h
Log Message:
-----------
Cherry-pick 258293@main (f28f93033a2c).
https://bugs.webkit.org/show_bug.cgi?id=249775
[GStreamer] ImageDecoder fixes
https://bugs.webkit.org/show_bug.cgi?id=249775
Reviewed by Xabier Rodriguez-Calvar.
Before tearing down the decoder pipeline it is good practice to disconnect
all message bus handlers
and also the decodebin pad-added signal handler.
* Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.cpp:
(WebCore::ImageDecoderGStreamer::InnerDecoder::~InnerDecoder):
* Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.h:
Canonical link: https://commits.webkit.org/258293@main
Commit: 57d646dd06a7555d91af8d0132b92f0f61a81a2a
https://github.com/WebKit/WebKit/commit/57d646dd06a7555d91af8d0132b92f0f61a81a2a
Author: Matthieu Dubet <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/css/CSSSelector.h
Log Message:
-----------
Cherry-pick 258339@main (a7844f97ea72).
https://bugs.webkit.org/show_bug.cgi?id=249902
Fix CSSSelector copy constructor bug
https://bugs.webkit.org/show_bug.cgi?id=249902
rdar://103723429
Reviewed by Tim Nguyen.
Typo ("if" instead of "if else") which in some rare
cases can write garbage in the Data union.
* Source/WebCore/css/CSSSelector.h:
(WebCore::CSSSelector::CSSSelector):
Canonical link: https://commits.webkit.org/258339@main
Commit: af059576ee5e10f0e6231e0cb60be82556d20ca8
https://github.com/WebKit/WebKit/commit/af059576ee5e10f0e6231e0cb60be82556d20ca8
Author: Ahmad Saleem <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
A
LayoutTests/editing/execCommand/apply-inline-style-to-element-with-no-renderer-crash-expected.txt
A
LayoutTests/editing/execCommand/apply-inline-style-to-element-with-no-renderer-crash.html
A
LayoutTests/platform/mac-wk1/editing/execCommand/apply-inline-style-to-element-with-no-renderer-crash-expected.txt
M Source/WebCore/editing/ApplyStyleCommand.cpp
Log Message:
-----------
Cherry-pick 258358@main (43e2b46ed602).
https://bugs.webkit.org/show_bug.cgi?id=249898
Splitting text can leave 'start' and 'end' Positions without renderers
Splitting text can leave 'start' and 'end' Positions without renderers
https://bugs.webkit.org/show_bug.cgi?id=249898
Reviewed by Ryosuke Niwa.
Merge -
https://chromium.googlesource.com/chromium/blink/+/d538920cd38e1a59c914f81f63757642466c4f46
When establishing new start and end positions in
ApplyStyleCommand::applyInlineStyle()
be sure to return early if either of them end up null, just as we do if
either of
them are null initially.
In this test case execCommand('CreateLink') adds an anchor HTML element in
an SVG
namespace so the text underneath validly does not receive a renderer.
Without a renderer
the text won't get a visible position value for the command so there's
nothing to do but
bail.
* Source/WebCore/editing/ApplyStyleCommand.cpp:
(ApplyStyleCommand::applyInlineStyle): Add early return if 'start' or 'end'
positions are null
(ApplyStyleCommand::shouldSplitTextElement): Add ASSERT for position to be
not null
*
LayoutTests/editing/execCommand/apply-inline-style-to-element-with-no-renderer-crash.html:
Add Test Case
*
LayoutTests/editing/execCommand/apply-inline-style-to-element-with-no-renderer-crash-expected.txt:
Add Test Case Expectation
*
LayoutTests/platform/mac-wk1/editing/execCommand/apply-inline-style-to-element-with-no-renderer-crash-expected.txt
Canonical link: https://commits.webkit.org/258358@main
Commit: 55091541b7e48b937565c21b90441197170209e8
https://github.com/WebKit/WebKit/commit/55091541b7e48b937565c21b90441197170209e8
Author: Carlos Garcia Campos <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WTF/wtf/glib/RunLoopSourcePriority.h
M Source/WebKit/NetworkProcess/cache/NetworkCacheIOChannel.h
M Source/WebKit/NetworkProcess/cache/NetworkCacheIOChannelGLib.cpp
M Source/WebKit/NetworkProcess/cache/NetworkCacheStorage.cpp
Log Message:
-----------
Cherry-pick 258379@main (5b9af92f602e).
https://bugs.webkit.org/show_bug.cgi?id=232629
[GLIB] Many network process crashes when running WPT tests
https://bugs.webkit.org/show_bug.cgi?id=232629
Reviewed by Michael Catanzaro.
Stop using GLib async APIs for network cache IOChannel implementation,
and use the sync API from a thread instead. The async API ends up doing
the job in a thread because file streams are not pollable. The problem
is that the internal GThreadPool tries to change the thread scheduler
setting and it fails when the current thread uses the idle scheduler,
which is the case of disk cache background threads. This reverts the
workaround introduced in 244519@main.
* Source/WTF/wtf/glib/RunLoopSourcePriority.h:
* Source/WebKit/NetworkProcess/cache/NetworkCacheIOChannel.h:
(WebKit::NetworkCache::IOChannel::isOpened const):
* Source/WebKit/NetworkProcess/cache/NetworkCacheIOChannelGLib.cpp:
(WebKit::NetworkCache::IOChannel::IOChannel):
(WebKit::NetworkCache::IOChannel::read):
(WebKit::NetworkCache::IOChannel::write):
(WebKit::NetworkCache::fillDataFromReadBuffer): Deleted.
(WebKit::NetworkCache::inputStreamReadReadyCallback): Deleted.
(WebKit::NetworkCache::IOChannel::readSyncInThread): Deleted.
(WebKit::NetworkCache::outputStreamWriteReadyCallback): Deleted.
* Source/WebKit/NetworkProcess/cache/NetworkCacheStorage.cpp:
(WebKit::NetworkCache::Storage::Storage):
(WebKit::NetworkCache::qosForBackgroundIOQueue): Deleted.
Canonical link: https://commits.webkit.org/258379@main
Commit: ed5857e614b0e37b2faad97b179d50b5149db7d5
https://github.com/WebKit/WebKit/commit/ed5857e614b0e37b2faad97b179d50b5149db7d5
Author: Wenson Hsieh <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
A
LayoutTests/http/tests/contentfiltering/load-event-in-allowed-subframe-expected.txt
A
LayoutTests/http/tests/contentfiltering/load-event-in-allowed-subframe.html
A LayoutTests/http/tests/contentfiltering/resources/lots-of-text.html
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
Log Message:
-----------
Cherry-pick 258394@main (5d11f0377c18).
https://bugs.webkit.org/show_bug.cgi?id=249811
REGRESSION (248723@main): Videos on bbc.co.uk fail to load when content
filtering is enabled
https://bugs.webkit.org/show_bug.cgi?id=249811
rdar://103247851
Reviewed by Brent Fulgham and Alex Christensen.
On articles on bbc.co.uk, video elements are embedded inside subframes, and
are only interactive
once the containing subframe has finished loading (i.e. dispatched the
"load" event). In the case
where:
1. Content filtering is enabled, and also happens in the network process
via the
`CONTENT_FILTERING_IN_NETWORKING_PROCESS` codepath new in iOS 16/macOS
Ventura.
2. The subframe is loaded from a disk cache entry (as opposed to over the
network, or in memory
cache).
...we end up never dispatching the load event on the subframe, due to the
fact that the
corresponding `WebCore::SubresourceLoader` driving the subframe load never
gets notified that
loading finished. This is because, in following code within the network
process (in the codepath
marked below), we exit early after delivering the cached data to the
content filter, before either
sending `WebResourceLoader::DidReceiveResource` or
`WebResourceLoader::DidFinishResourceLoad` (the
latter of which we use in the case where we don't already have a shareable
resource handle). To fix
this, we simply pull the logic to dispatch
`WebResourceLoader::DidFinishResourceLoad` out into a
separate callback, and invoke it from both places.
```
#if ENABLE(SHAREABLE_RESOURCE)
if (!entry->shareableResourceHandle().isNull()) {
#if ENABLE(CONTENT_FILTERING_IN_NETWORKING_PROCESS)
if (m_contentFilter &&
!m_contentFilter->continueAfterDataReceived(entry->buffer()->makeContiguous(),
entry->buffer()->size())) {
m_contentFilter->continueAfterNotifyFinished(m_parameters.request.url());
m_contentFilter->stopFilteringMainResource();
// <-------
return;
}
#endif
send(Messages::WebResourceLoader::DidReceiveResource(entry->shareableResourceHandle()));
return;
}
#endif
```
Note that we prefer dispatching `DidFinishResourceLoad` over
`DidReceiveResource` below (which we
would normally use in this shareable resource handle codepath), since the
resource loader in the web
process would already have received the data when content filtering is
enabled, so sending the
entire cached resource handle again is redundant.
Test: http/tests/contentfiltering/load-event-in-allowed-subframe.html
*
LayoutTests/http/tests/contentfiltering/load-event-in-allowed-subframe-expected.txt:
Added.
*
LayoutTests/http/tests/contentfiltering/load-event-in-allowed-subframe.html:
Added.
* LayoutTests/http/tests/contentfiltering/resources/lots-of-text.html:
Added.
Add a new test resource that consists of an HTML page that contains a large
amount of text. This
ensures that we'll attempt to store it in disk cache, which is a necessary
part of reproducing this
bug.
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::sendResultForCacheEntry):
Dispatch `WebResourceLoader::DidFinishResourceLoad` in both content
filtering codepaths when
`CONTENT_FILTERING_IN_NETWORKING_PROCESS` is enabled.
Canonical link: https://commits.webkit.org/258394@main
Commit: 618d4ac2c359e5446785beb8e7bf8cb42d14677f
https://github.com/WebKit/WebKit/commit/618d4ac2c359e5446785beb8e7bf8cb42d14677f
Author: Alex Christensen <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WTF/wtf/URLHelpers.cpp
M Tools/TestWebKitAPI/Tests/WTF/cocoa/URLExtras.mm
Log Message:
-----------
Cherry-pick 258404@main (71a3b490a749).
https://bugs.webkit.org/show_bug.cgi?id=250035
Don't punycode U+00ED
https://bugs.webkit.org/show_bug.cgi?id=250035
rdar://103841792
Reviewed by Tim Horton.
It is visually different than 'i' and it is used in several languages that
have many native speakers.
It is also not punycoded in Chrome or Firefox.
* Source/WTF/wtf/URLHelpers.cpp:
(WTF::URLHelpers::isLookalikeCharacter):
* Tools/TestWebKitAPI/Tests/WTF/cocoa/URLExtras.mm:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/258404@main
Commit: 44079dc9d44b03edc6631b7b842356b0c6a6cf96
https://github.com/WebKit/WebKit/commit/44079dc9d44b03edc6631b7b842356b0c6a6cf96
Author: Don Olmstead <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/cmake/FindWPE.cmake
M Source/cmake/OptionsPlayStation.cmake
Log Message:
-----------
Cherry-pick 258421@main (d2477fc765e2).
https://bugs.webkit.org/show_bug.cgi?id=250054
[CMake] Fix version detection of libwpe
https://bugs.webkit.org/show_bug.cgi?id=250054
Reviewed by Michael Catanzaro.
The wrong header was being searched for the version number. Also the
regex wasn't correct.
Bump the version required by PlayStation to be 1.14.
* Source/cmake/FindWPE.cmake:
* Source/cmake/OptionsPlayStation.cmake:
Canonical link: https://commits.webkit.org/258421@main
Commit: 1b868d373bede773c6d53049a1904ed5b729f44c
https://github.com/WebKit/WebKit/commit/1b868d373bede773c6d53049a1904ed5b729f44c
Author: Žan Doberšek <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WTF/wtf/text/StringConcatenate.h
M Tools/TestWebKitAPI/Tests/WTF/StringConcatenate.cpp
Log Message:
-----------
Cherry-pick 258446@main (b41ac5266fe9).
https://bugs.webkit.org/show_bug.cgi?id=250070
StringConcatenate's StringTypeAdapter<std::tuple<>> incorrectly writes into
a 16-bit destination
https://bugs.webkit.org/show_bug.cgi?id=250070
Reviewed by Sam Weinig.
When StringTypeAdapter<std::tuple<...>> writes into any destination string,
the
offset value shouldn't be multiplied by the size of the string's character
type.
Pointer arithmetic will take care of that on its own.
Test case in the StringConcatenate suite is provided, covering both 8-bit
and
16-bit strings constructed partially or completely from a tuple object.
The StringTypeAdapter specialization is also adjusted to only keep a
reference
to the tuple object, and not copy it. Passes over the tuple elements are
done
with lambdas that take arguments through const lvalue references, avoiding
any
copying of the contained elements.
* Source/WTF/wtf/text/StringConcatenate.h:
(WTF::StringTypeAdapter<std::tuple<StringTypes::StringTypeAdapter):
(WTF::StringTypeAdapter<std::tuple<StringTypes::writeTo const):
(WTF::StringTypeAdapter<std::tuple<StringTypes::computeLength):
(WTF::StringTypeAdapter<std::tuple<StringTypes::computeIs8Bit):
* Tools/TestWebKitAPI/Tests/WTF/StringConcatenate.cpp:
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/258446@main
Commit: 0478e2c8d3588428b73f7a74f3d903c10979f16b
https://github.com/WebKit/WebKit/commit/0478e2c8d3588428b73f7a74f3d903c10979f16b
Author: Ahmad Saleem <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
A LayoutTests/fast/text/bidi-replace-runs-crash-expected.txt
A LayoutTests/fast/text/bidi-replace-runs-crash.html
M Source/WebCore/platform/text/BidiRunList.h
Log Message:
-----------
Cherry-pick 258465@main (f1fd9e9795a6).
https://bugs.webkit.org/show_bug.cgi?id=249968
Potential Assertion Fix - Fix loop condition in
BidiRunList::replaceRunWithRuns
https://bugs.webkit.org/show_bug.cgi?id=249968
Reviewed by Alan Baradlay.
Merge - https://src.chromium.org/viewvc/blink?view=revision&revision=179068
This patch is to potentially fix an assertion on debug builds by fixing a
loop condition in
BidiRunList::replaceRunWithRuns to check if next run exists before
accessing it.
* Source/WebCore/platform/text/BidiRunList.h:
(BidiRunList<Run>::replaceRunwithRuns): update 'while' loop
* LayoutTests/fast/text/bidi-replace-runs-crash.html: Add Test Case
* LayoutTests/fast/text/bidi-replace-runs-crash-expected.txt: Add Test Case
Expectation
Canonical link: https://commits.webkit.org/258465@main
Commit: 828a07a6e77e86936f95a575e8bd925a3bf57216
https://github.com/WebKit/WebKit/commit/828a07a6e77e86936f95a575e8bd925a3bf57216
Author: Carlos Garcia Campos <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebKit/WebProcess/WebProcess.cpp
Log Message:
-----------
Cherry-pick 258380@main (ee52175fab81).
https://bugs.webkit.org/show_bug.cgi?id=249272
[WPE][GTK] Robustly handle subprocess leaks
https://bugs.webkit.org/show_bug.cgi?id=249272
Reviewed by Michael Catanzaro.
Call _exit from a secondary thread after the connection is closed if the
main thread doesn't exit in 10 seconds.
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::callExitSoon):
(WebKit::WebProcess::initializeConnection):
Canonical link: https://commits.webkit.org/258380@main
Commit: 868aa8df7bc8eb433d64b264b86f3492a648b625
https://github.com/WebKit/WebKit/commit/868aa8df7bc8eb433d64b264b86f3492a648b625
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp
Log Message:
-----------
Cherry-pick 258656@main (8ffb0f29be5a).
https://bugs.webkit.org/show_bug.cgi?id=249937
[GStreamer][WebRTC] Minor end-point improvements
https://bugs.webkit.org/show_bug.cgi?id=249937
Reviewed by Xabier Rodriguez-Calvar.
Avoid some duplicate error reporting and improved instrumentation for
pipeline dumping.
* Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp:
(WebCore::GStreamerMediaEndpoint::initializePipeline):
(WebCore::GStreamerMediaEndpoint::requestAuxiliarySender):
Canonical link: https://commits.webkit.org/258656@main
Commit: 019d53f3d4e52a717d137561abf5481c60ced080
https://github.com/WebKit/WebKit/commit/019d53f3d4e52a717d137561abf5481c60ced080
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
Log Message:
-----------
Cherry-pick 258657@main (776ff1f8adf9).
https://bugs.webkit.org/show_bug.cgi?id=249995
[GStreamer] Misc fixes in video encoder/decoder probing support
https://bugs.webkit.org/show_bug.cgi?id=249995
Reviewed by Xabier Rodriguez-Calvar.
When multiple elements were able to support the given format only the first
matching element factory
was stored in the lookup result. We also now ignore the vpxalphadecodebin
wrapper elements when
probing vpx decoding capabilities. Those elements are meant to be used by
decodebin and won't
negotiate input non-alpha caps.
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
(WebCore::GStreamerRegistryScanner::ElementFactories::hasElementForMediaType
const):
(WebCore::GStreamerRegistryScanner::initializeDecoders):
Canonical link: https://commits.webkit.org/258657@main
Commit: f1185dc9769664c193ac38f459ccefd547617d4d
https://github.com/WebKit/WebKit/commit/f1185dc9769664c193ac38f459ccefd547617d4d
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp
M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.h
M
Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingMediaSourceGStreamer.h
Log Message:
-----------
Cherry-pick 258658@main (4c9aa3f06f5d).
https://bugs.webkit.org/show_bug.cgi?id=250007
[GStreamer][WebRTC] Improved msid support
https://bugs.webkit.org/show_bug.cgi?id=250007
Reviewed by Xabier Rodriguez-Calvar.
GstWebRTCBin can now store the MediaStream ID as a pad property. Fallback
to previously used CNAME
otherwise. See also
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3106.
* Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp:
(WebCore::GStreamerMediaEndpoint::configureAndLinkSource):
(WebCore::GStreamerMediaEndpoint::requestPad):
(WebCore::GStreamerMediaEndpoint::addRemoteStream):
* Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.h:
*
Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingMediaSourceGStreamer.h:
(WebCore::RealtimeOutgoingMediaSourceGStreamer::mediaStreamID const):
Canonical link: https://commits.webkit.org/258658@main
Commit: 7074b422dd12078573dfb8ca1854a97451e9f1a4
https://github.com/WebKit/WebKit/commit/7074b422dd12078573dfb8ca1854a97451e9f1a4
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/Modules/mediastream/gstreamer/GStreamerStatsCollector.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
M Source/WebCore/platform/mediastream/RealtimeMediaSource.h
M
Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp
M
Source/WebCore/platform/mediastream/gstreamer/RealtimeIncomingVideoSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 258659@main (ecd45a098ed5).
https://bugs.webkit.org/show_bug.cgi?id=249940
[GStreamer][WebRTC] Improved statistics support
https://bugs.webkit.org/show_bug.cgi?id=249940
Reviewed by Xabier Rodriguez-Calvar.
Fill the `kind` attribute in RtpStreamStats and also a few more video frame
related attributes for
inbound rtp stats. In order to support extended stats gathering, the
queryDecodedVideoFramesCount()
virtual method in VideoFrameObserver was replaced by a more generic
queryAdditionalStats method.
* Source/WebCore/Modules/mediastream/gstreamer/GStreamerStatsCollector.cpp:
(WebCore::fillRTCRTPStreamStats):
(WebCore::fillInboundRTPStreamStats):
(WebCore::fillRTCTransportStats):
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::configureVideoDecoder):
(WebCore::MediaPlayerPrivateGStreamer::updateVideoSinkStatistics):
(WebCore::MediaPlayerPrivateGStreamer::videoPlaybackQualityMetrics):
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
* Source/WebCore/platform/mediastream/RealtimeMediaSource.h:
*
Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:
*
Source/WebCore/platform/mediastream/gstreamer/RealtimeIncomingVideoSourceGStreamer.cpp:
(WebCore::RealtimeIncomingVideoSourceGStreamer::stats):
Canonical link: https://commits.webkit.org/258659@main
Commit: 29f0db98a3b6ecd20fa55caf108251c4c3e26e25
https://github.com/WebKit/WebKit/commit/29f0db98a3b6ecd20fa55caf108251c4c3e26e25
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M
Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp
M
Source/WebCore/platform/mediastream/gstreamer/RealtimeMediaSourceCenterGStreamer.cpp
Log Message:
-----------
Cherry-pick 258660@main (8c81bbe3f8e2).
https://bugs.webkit.org/show_bug.cgi?id=249939
[GStreamer][MediaStream] Minor logging and include fixes
https://bugs.webkit.org/show_bug.cgi?id=249939
Reviewed by Xabier Rodriguez-Calvar.
*
Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:
The audio sample
handling and logging is now more coherent with the video frames handling
code path.
*
Source/WebCore/platform/mediastream/gstreamer/RealtimeMediaSourceCenterGStreamer.cpp:
Remove
un-needed includes.
Canonical link: https://commits.webkit.org/258660@main
Commit: 6239e5c1798dd9e9a051b658db94af3292e0b2ab
https://github.com/WebKit/WebKit/commit/6239e5c1798dd9e9a051b658db94af3292e0b2ab
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M
Source/WebCore/platform/mediastream/gstreamer/GStreamerAudioCaptureSource.cpp
M Source/WebCore/platform/mediastream/gstreamer/GStreamerAudioCapturer.cpp
M Source/WebCore/platform/mediastream/gstreamer/GStreamerCapturer.cpp
M Source/WebCore/platform/mediastream/gstreamer/GStreamerCapturer.h
M
Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingAudioSourceGStreamer.cpp
M
Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingVideoSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 258662@main (4f70db078a9a).
https://bugs.webkit.org/show_bug.cgi?id=249938
[GStreamer][MediaStream] Misc media capture improvements
https://bugs.webkit.org/show_bug.cgi?id=249938
Reviewed by Xabier Rodriguez-Calvar.
Video frame metadata was attached only for mock sources. There's no need
for a tee in the capturer
pipeline because there's never more than one client. Multiple observers
watch for samples received
by the sink. And a few other drive-by and coding style cleanups.
*
Source/WebCore/platform/mediastream/gstreamer/GStreamerAudioCaptureSource.cpp:
(WebCore::GStreamerAudioCaptureSource::newSampleCallback):
* Source/WebCore/platform/mediastream/gstreamer/GStreamerAudioCapturer.cpp:
(WebCore::initializeDebugCategory):
(WebCore::GStreamerAudioCapturer::GStreamerAudioCapturer):
(WebCore::GStreamerAudioCapturer::createConverter):
(WebCore::GStreamerAudioCapturer::setSampleRate):
* Source/WebCore/platform/mediastream/gstreamer/GStreamerCapturer.cpp:
(WebCore::GStreamerCapturer::createSource):
(WebCore::GStreamerCapturer::setupPipeline):
(WebCore::GStreamerCapturer::makeElement):
(WebCore::GStreamerCapturer::addSink): Deleted.
* Source/WebCore/platform/mediastream/gstreamer/GStreamerCapturer.h:
*
Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingAudioSourceGStreamer.cpp:
*
Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingVideoSourceGStreamer.cpp:
Canonical link: https://commits.webkit.org/258662@main
Commit: 195653202db2df8a2e99252db2dd48532cea9591
https://github.com/WebKit/WebKit/commit/195653202db2df8a2e99252db2dd48532cea9591
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
M Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoEncoder.cpp
M Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoEncoder.h
Log Message:
-----------
Cherry-pick 258663@main (2295aff2e623).
https://bugs.webkit.org/show_bug.cgi?id=249936
[GStreamer][WebRTC] Video encoder capabilities probing support
https://bugs.webkit.org/show_bug.cgi?id=249936
Reviewed by Xabier Rodriguez-Calvar.
The registry scanner is now able to check the H.264 encoding capabilies of
the host. Also, when more
than one platform encoder is capable of encoding to the target format, only
the one with the highest
rank is selected.
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
(WebCore::GStreamerRegistryScanner::fillVideoRtpCapabilities):
* Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoEncoder.cpp:
(webrtcVideoEncoderFindForFormat):
(webrtcVideoEncoderSupportsFormat):
(webrtcVideoEncoderSetFormat):
* Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoEncoder.h:
Canonical link: https://commits.webkit.org/258663@main
Commit: b2ae186df54857c2d2b13210644adadae0e49a74
https://github.com/WebKit/WebKit/commit/b2ae186df54857c2d2b13210644adadae0e49a74
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp
M Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.h
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.h
M Source/WebCore/platform/mediastream/gstreamer/GStreamerWebRTCProvider.cpp
Log Message:
-----------
Cherry-pick 258848@main (8c38ebd63c97).
https://bugs.webkit.org/show_bug.cgi?id=250480
REGRESSION(258663@main) [GStreamer] MIME API test crashes due to GStreamer
being initialized in UIProcess
https://bugs.webkit.org/show_bug.cgi?id=250480
Reviewed by Xabier Rodriguez-Calvar.
The registry no longer directly registers GStreamer elements. Instead it is
done from call-sites,
such as the WebRTC provider, when needed. Also the scanner is now able to
refresh its internal
state, this is needed in situations where the singleton might have been
created before the
registration of additional elements.
* Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp:
(WebCore::registerVideoEncoder):
(WebCore::registerWebKitGStreamerElements):
(WebCore::registerWebKitGStreamerVideoEncoder):
* Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.h:
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
(WebCore::GStreamerRegistryScanner::singletonNeedsInitialization):
(WebCore::GStreamerRegistryScanner::singleton):
(WebCore::GStreamerRegistryScanner::GStreamerRegistryScanner):
(WebCore::GStreamerRegistryScanner::refresh):
(WebCore::GStreamerRegistryScanner::initializeDecoders):
(WebCore::GStreamerRegistryScanner::initializeEncoders):
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.h:
* Source/WebCore/platform/mediastream/gstreamer/GStreamerWebRTCProvider.cpp:
(WebCore::GStreamerWebRTCProvider::initializeVideoEncodingCapabilities):
* Tools/TestWebKitAPI/glib/TestExpectations.json:
Canonical link: https://commits.webkit.org/258848@main
Commit: d1774eeb96d93b07d725022bc399ea9b71e5868a
https://github.com/WebKit/WebKit/commit/d1774eeb96d93b07d725022bc399ea9b71e5868a
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
M Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoEncoder.cpp
M
Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingVideoSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 258666@main (9e4ed340f437).
https://bugs.webkit.org/show_bug.cgi?id=249941
[GStreamer][WebRTC] VAAPI encoders support
https://bugs.webkit.org/show_bug.cgi?id=249941
Reviewed by Xabier Rodriguez-Calvar.
Basic support for H.264 and H.265 VAAPI encoders. The H.265 probing is very
minimal at the moment.
Support for VP8/VP9/AV1 will be added later on (I don't have GPUs
supporting those codecs).
Implicitely depends on https://github.com/WebKit/WebKit/pull/8094 and
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3616.
The videorate element in the encoder bin was triggering issues and
flakyness in some tests. I think
it's not really required actually, but a videoscale is good to have though.
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
(WebCore::GStreamerRegistryScanner::fillVideoRtpCapabilities):
* Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoEncoder.cpp:
(webrtcVideoEncoderSetEncoder):
(webkit_webrtc_video_encoder_class_init):
*
Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingVideoSourceGStreamer.cpp:
(WebCore::RealtimeOutgoingVideoSourceGStreamer::setPayloadType):
Canonical link: https://commits.webkit.org/258666@main
Commit: 7b117871bebfdcf66bb1a1ff03d99a85ed6be272
https://github.com/WebKit/WebKit/commit/7b117871bebfdcf66bb1a1ff03d99a85ed6be272
Author: Alexander Kanavin <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/cmake/FindGI.cmake
Log Message:
-----------
Cherry-pick 258828@main (b95db349375a).
https://bugs.webkit.org/show_bug.cgi?id=250195
Propagate CFLAGS to introspection targets
https://bugs.webkit.org/show_bug.cgi?id=250195
Reviewed by Adrian Perez de Castro.
Otherwise, important things do not get passed to the compiler in cross
compiling with a sysroot scenario:
In file included from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot-native/usr/lib/x86_64-poky-linux/gcc/x86_64-poky-linux/11.2.0/include-fixed/syslimits.h:7,
from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot-native/usr/lib/x86_64-poky-linux/gcc/x86_64-poky-linux/11.2.0/include-fixed/limits.h:34,
from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot/usr/lib/glib-2.0/include/glibconfig.h:11,
from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot/usr/include/glib-2.0/glib/gtypes.h:32,
from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot/usr/include/glib-2.0/glib/galloca.h:32,
from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot/usr/include/glib-2.0/glib.h:30,
from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/build/Source/JavaScriptCore/tmp-introspectb51ks33n/JavaScriptCore-4.0.c:2:
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot-native/usr/lib/x86_64-poky-linux/gcc/x86_64-poky-linux/11.2.0/include-fixed/limits.h:203:75:
error: no include path in which to search for limits.h
203 | #include_next <limits.h> /* recurse down to the real
one */
|
^
In file included from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot/usr/include/glib-2.0/glib/galloca.h:32,
from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot/usr/include/glib-2.0/glib.h:30,
from
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/build/Source/JavaScriptCore/tmp-introspectb51ks33n/JavaScriptCore-4.0.c:2:
/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot/usr/include/glib-2.0/glib/gtypes.h:35:10:
fatal error: time.h: No such file or directory
35 | #include <time.h>
| ^~~~~~~~
compilation terminated.
Traceback (most recent call last):
File
"/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot-native/usr/lib/python3.10/distutils/unixccompiler.py",
line 117, in _compile
self.spawn(compiler_so + cc_args + [src, '-o', obj] +
File
"/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot-native/usr/lib/python3.10/distutils/ccompiler.py",
line 910, in spawn
spawn(cmd, dry_run=self.dry_run)
File
"/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot-native/usr/lib/python3.10/distutils/spawn.py",
line 91, in spawn
raise DistutilsExecError(
distutils.errors.DistutilsExecError: command
'/srv/work/alex/poky/build-64-alt/tmp/work/core2-64-poky-linux/webkitgtk/2.36.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc'
failed with exit code 1
* Source/cmake/FindGI.cmake:
Canonical link: https://commits.webkit.org/258828@main
Commit: 1dd4ef7ae5f35d4f840124114f2856fb881367f4
https://github.com/WebKit/WebKit/commit/1dd4ef7ae5f35d4f840124114f2856fb881367f4
Author: Ahmad Saleem <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M Source/WebCore/platform/sql/SQLiteDatabase.cpp
Log Message:
-----------
Cherry-pick 258673@main (8217dce03e25).
https://bugs.webkit.org/show_bug.cgi?id=249598
Fix potential VACCUM error by counting destructor
https://bugs.webkit.org/show_bug.cgi?id=249598
Reviewed by Ben Nham.
This patch is to fix error where if vacuum mode is not set-up initially, it
can lead to vacuum run being blocked.
This patch will fix this potential error by counting on destructor.
* Source/WebCore/platform/sql/SQLiteDatabase.cpp:
(SQLiteDatabase::turnOnIncrementalAutoVacuum): Add 'int' variable and wrap
function and count on destructor on introduced variable
Canonical link: https://commits.webkit.org/258673@main
Commit: 3cd56162eedfec161ea1e78c674ea50aed92d117
https://github.com/WebKit/WebKit/commit/3cd56162eedfec161ea1e78c674ea50aed92d117
Author: Philippe Normand <[email protected]>
Date: 2023-01-26 (Thu, 26 Jan 2023)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
Log Message:
-----------
Cherry-pick 258717@main (e2afda4dd0ab).
https://bugs.webkit.org/show_bug.cgi?id=174458
[Gstreamer][HLS] Unable to play TED videos
https://bugs.webkit.org/show_bug.cgi?id=174458
Reviewed by Xabier Rodriguez-Calvar.
Disable HLS support by default in GStreamer ports. The underlying GStreamer
hlsdemux element is not
receiving much maintenance and its replacement, hlsdemux2, cannot be used
by WebKit due to
sandboxing requirements.
Most websites should now fallback to MSE if HLS is not supported by the
User-Agent. This was checked
on TED and Apple developer websites.
HLS support can be re-enabled at runtime by setting the
`WEBKIT_GST_ENABLE_HLS_SUPPORT=1`
environment variable.
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
(WebCore::GStreamerRegistryScanner::initializeDecoders):
Canonical link: https://commits.webkit.org/258717@main
Commit: 402e377d30ba6dc44564fca8bf0404890bf48c94
https://github.com/WebKit/WebKit/commit/402e377d30ba6dc44564fca8bf0404890bf48c94
Author: Youenn Fablet <[email protected]>
Date: 2023-01-27 (Fri, 27 Jan 2023)
Changed paths:
M Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.cpp
Log Message:
-----------
Cherry-pick 258726@main (205fbbb4b2d6).
https://bugs.webkit.org/show_bug.cgi?id=250373
Fix buggy assert in WebSWContextManagerConnection::updateAppInitiatedValue
https://bugs.webkit.org/show_bug.cgi?id=250373
rdar://problem/104067420
Reviewed by Chris Dumez.
We receive the message from a work queue and should account for it.
* Source/WebKit/WebProcess/Storage/WebSWContextManagerConnection.cpp:
(WebKit::WebSWContextManagerConnection::updateAppInitiatedValue):
Canonical link: https://commits.webkit.org/258726@main
Compare: https://github.com/WebKit/WebKit/compare/65ae701fd309...402e377d30ba
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
