Branch: refs/heads/webkitglib/2.44
Home: https://github.com/WebKit/WebKit
Commit: c683dc77add674d8b77a776cc6b0d0a6c61f2c18
https://github.com/WebKit/WebKit/commit/c683dc77add674d8b77a776cc6b0d0a6c61f2c18
Author: Philippe Normand <[email protected]>
Date: 2024-07-29 (Mon, 29 Jul 2024)
Changed paths:
M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp
Log Message:
-----------
Cherry-pick 276412@main (da50e63df7f3).
https://bugs.webkit.org/show_bug.cgi?id=271243
[GStreamer][WebRTC] webrtc/connection-state.html started failing after
update to 1.24.0
https://bugs.webkit.org/show_bug.cgi?id=271243
<rdar://problem/125014192>
Reviewed by Xabier Rodriguez-Calvar.
The `doneGatheringCandidates()` method is called by the
PeerConnectionBackend when it's notified
from gst-webrtc that the ICE gathering is finished, so we don't need to
call it ourselves. The
end-of-candidates SDP attribute shouldn't appear in the offer/answer the
end-point reports either.
This is covered by the webrtc/libwebrtc/descriptionGetters.html test.
* LayoutTests/platform/glib/TestExpectations:
* Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp:
(WebCore::fetchDescription):
(WebCore::GStreamerMediaEndpoint::doSetLocalDescription):
(WebCore::GStreamerMediaEndpoint::doSetRemoteDescription):
(WebCore::GStreamerMediaEndpoint::onIceCandidate):
Canonical link: https://commits.webkit.org/276412@main
Canonical link: https://commits.webkit.org/274313.306@webkitglib/2.44
Commit: f4c108b7b1b841bf883f05af505dccc176bcf564
https://github.com/WebKit/WebKit/commit/f4c108b7b1b841bf883f05af505dccc176bcf564
Author: Ahmad Saleem <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/webrtc/RTCSctpTransport-maxMessageSize-expected.txt
M Source/WebCore/Modules/mediastream/RTCSctpTransport.h
Log Message:
-----------
Cherry-pick 279039@main (868f20242ed9).
https://bugs.webkit.org/show_bug.cgi?id=274025
`m_maxMessageSize` should be `infinity()` instead of `max()` in
`RTCSctpTransport.h`
https://bugs.webkit.org/show_bug.cgi?id=274025
rdar://problem/128306030
Reviewed by Youenn Fablet.
This patch aligns WebKit with web specification [1]:
[1] https://w3c.github.io/webrtc-pc/#dfn-update-the-data-max-message-size
"If both remoteMaxMessageSize and canSendSize are 0, set
[[MaxMessageSize]] to the positive Infinity value."
* Source/WebCore/Modules/mediastream/RTCSctpTransport.h:
(double m_maxMessageSize):
*
LayoutTests/imported/w3c/web-platform-tests/webrtc/RTCSctpTransport-maxMessageSize-expected.txt:
Rebaselined
Canonical link: https://commits.webkit.org/279039@main
Canonical link: https://commits.webkit.org/274313.307@webkitglib/2.44
Commit: 4954333c2945eca30e9dc0d8acb0651100c95003
https://github.com/WebKit/WebKit/commit/4954333c2945eca30e9dc0d8acb0651100c95003
Author: Enrique Ocaña González <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
M
Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp
Log Message:
-----------
Cherry-pick 277541@main (40cfa6a61706).
https://bugs.webkit.org/show_bug.cgi?id=272167
[GStreamer] Ignore sinks position while seeking
https://bugs.webkit.org/show_bug.cgi?id=272167
Reviewed by Alicia Boya Garcia.
After removing MSE data, sinks get flushed and are not able to return
valid playback time. Some implementation return invalid time, 0.00 or
even some random value. This value may be then reported up to
HTMLMediaElement and that may be confusing to web applications.
This commit doesn't trust sinks position when pipeline is not prerolled,
as behavor is different across devices. The last cached position is used
instead.
To reflect better what's actually happening, isPipelineSeeking() has been
renamed as isPipelineWaitingPreroll() and the condition now also includes
pending states higher than paused.
Original author: Andrzej Surdej (https://github.com/asurdej-comcast)
See: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1302
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::isPipelineWaitingPreroll const):
Renamed from isPipelineSeeking().
(WebCore::MediaPlayerPrivateGStreamer::play): isPipelineSeeking() now named
as isPipelineWaitingPreroll().
(WebCore::MediaPlayerPrivateGStreamer::paused const): Ditto.
(WebCore::MediaPlayerPrivateGStreamer::changePipelineState): Ditto.
(WebCore::MediaPlayerPrivateGStreamer::playbackPosition const): Use
GST_CLOCK_TIME_NONE when the pipeline isn't prerolled. This will force the
usage of the target seek time (if possible) or the last cached position (in the
worst case).
(WebCore::MediaPlayerPrivateGStreamer::isPipelineSeeking const): Deleted.
Renamed to isPipelineWaitingPreroll().
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
isPipelineSeeking() now named as isPipelineWaitingPreroll().
*
Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:
(WebCore::MediaPlayerPrivateGStreamerMSE::updateStates):
isPipelineSeeking() now named as isPipelineWaitingPreroll().
Canonical link: https://commits.webkit.org/277541@main
Canonical link: https://commits.webkit.org/274313.308@webkitglib/2.44
Commit: 4224d948394c37bcdf6626ae397bfdc87fcec428
https://github.com/WebKit/WebKit/commit/4224d948394c37bcdf6626ae397bfdc87fcec428
Author: Philippe Normand <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
A
LayoutTests/media/media-source/media-source-video-play-holds-sleep-assertion-expected.txt
A
LayoutTests/media/media-source/media-source-video-play-holds-sleep-assertion.html
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
M
Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp
M
Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h
Log Message:
-----------
Cherry-pick 279943@main (6a650e644b1c).
https://bugs.webkit.org/show_bug.cgi?id=219354
[GStreamer][MSE] SleepDisabler not reliably created when playing YouTube
videos
https://bugs.webkit.org/show_bug.cgi?id=219354
Reviewed by Xabier Rodriguez-Calvar.
When playing videos the display screensaver should be disabled, and when
the video is paused it
should be re-enabled. This is mostly useful on desktop systems. The sleep
disabler is handled by
HTMLMediaElement.
Until this patch display sleep wasn't consistently disabled as a result of
playback request. By
notifying the MediaPlayer of successful GStreamer pipeline state changes
the HTMLMediaElement gets
another opportunity to update the sleep disabling state. This is done
already in the
MediaPlayerPrivateGStreamer::updateStates() method, but for some reason the
MSE player has a
different implementation of that method.
Test: media/media-source/media-source-video-play-holds-sleep-assertion.html
*
LayoutTests/media/media-source/media-source-video-play-holds-sleep-assertion-expected.txt:
Added.
*
LayoutTests/media/media-source/media-source-video-play-holds-sleep-assertion.html:
Added.
* LayoutTests/platform/mac-wk1/TestExpectations:
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::progressEventTimerFired):
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
*
Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:
(WebCore::MediaPlayerPrivateGStreamerMSE::pause):
(WebCore::MediaPlayerPrivateGStreamerMSE::checkPlayingConsistency):
(WebCore::MediaPlayerPrivateGStreamerMSE::setShouldDisableSleep):
(WebCore::MediaPlayerPrivateGStreamerMSE::updateStates):
(WebCore::MediaPlayerPrivateGStreamerMSE::timeIsProgressing const):
*
Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.h:
Canonical link: https://commits.webkit.org/279943@main
Canonical link: https://commits.webkit.org/274313.309@webkitglib/2.44
Commit: 58600bd00cb31d99936a843fdcb916d56bee6633
https://github.com/WebKit/WebKit/commit/58600bd00cb31d99936a843fdcb916d56bee6633
Author: Youenn Fablet <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/webrtc/RTCSctpTransport-maxMessageSize-expected.txt
M Source/WebCore/Modules/mediastream/PeerConnectionBackend.cpp
M Source/WebCore/Modules/mediastream/PeerConnectionBackend.h
M Source/WebCore/Modules/mediastream/RTCPeerConnection.cpp
M Source/WebCore/Modules/mediastream/RTCPeerConnection.h
M Source/WebCore/Modules/mediastream/RTCSctpTransport.cpp
M Source/WebCore/Modules/mediastream/RTCSctpTransport.h
M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp
M Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.cpp
Log Message:
-----------
Cherry-pick 279111@main (a270d67c5341).
https://bugs.webkit.org/show_bug.cgi?id=274442
Most of WPT webrtc/RTCSctpTransport-maxMessageSize.html tests are failing
https://bugs.webkit.org/show_bug.cgi?id=274442
rdar://128444396
Reviewed by Philippe Normand.
We implement https://w3c.github.io/webrtc-pc/#sctp-transport-update-mms.
This is called when successfully applying a SDP description as per
specification.
In this implementation, the assumption is that canSendSize is 0.
The specific value of 65536 is handled by libwebrtc.
*
LayoutTests/imported/w3c/web-platform-tests/webrtc/RTCSctpTransport-maxMessageSize-expected.txt:
* Source/WebCore/Modules/mediastream/PeerConnectionBackend.cpp:
(WebCore::PeerConnectionBackend::setLocalDescriptionSucceeded):
(WebCore::PeerConnectionBackend::setRemoteDescriptionSucceeded):
* Source/WebCore/Modules/mediastream/PeerConnectionBackend.h:
* Source/WebCore/Modules/mediastream/RTCPeerConnection.cpp:
(WebCore::RTCPeerConnection::updateSctpBackend):
* Source/WebCore/Modules/mediastream/RTCPeerConnection.h:
* Source/WebCore/Modules/mediastream/RTCSctpTransport.cpp:
(WebCore::RTCSctpTransport::onStateChanged):
(WebCore::RTCSctpTransport::updateMaxMessageSize):
* Source/WebCore/Modules/mediastream/RTCSctpTransport.h:
* Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp:
(WebCore::GStreamerMediaEndpoint::doSetLocalDescription):
(WebCore::GStreamerMediaEndpoint::doSetRemoteDescription):
* Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.cpp:
(WebCore::SctpTransportState::maxMessageSize const):
(WebCore::LibWebRTCMediaEndpoint::setLocalSessionDescriptionSucceeded):
(WebCore::LibWebRTCMediaEndpoint::setRemoteSessionDescriptionSucceeded):
Canonical link: https://commits.webkit.org/279111@main
Canonical link: https://commits.webkit.org/274313.310@webkitglib/2.44
Commit: c770aa725ac83fc4ce1a802091ffc07113db6122
https://github.com/WebKit/WebKit/commit/c770aa725ac83fc4ce1a802091ffc07113db6122
Author: Georges Basile Stavracas Neto <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp
Log Message:
-----------
Cherry-pick 280770@main (e949df8b32a3).
https://bugs.webkit.org/show_bug.cgi?id=240522
[GTK][WPE][a11y] Allow receiving event listener signals from the a11y bus
https://bugs.webkit.org/show_bug.cgi?id=240522
Reviewed by Michael Catanzaro.
When a process - usually an AT - registers event listeners, AT-SPI
broadcasts the EventListenerRegistered signal so that clients know
about it. The EventListenerDeregistered signal is broadcasted when
event listeners are removed.
The web process monitors for these signal so that it can reduce the
number of signal emissions on the a11y bus. Now consider that the web
process runs in a sandbox (most of the time anyway), either by using
Bubblewrap directly, or flatpak-spawn. These sandboxing mechanisms
filter D-Bus messages and signals, including on the a11y bus. And
here's the problem: both of them end up preventing the web process to
receive the event listener signals!
As a consequence, the web process never learns when the user turns
on or off the screen reader, or auxiliary accessibility programs.
And without that knowledge, the web process doesn't emit any event
necessary for proper accessibility.
Allow the Bubblewrap sandbox to receive the EventListenerRegistered
and EventListenerDeregistered signals from org.a11y.atspi.Registry.
This is safe, as there is insufficient information in these signals
for any malicious usage, and the bus name in the messages are already
from apps that purposefully advertise themselves.
A similar patch is proposed for Flatpak, and there's nothing to be
done from WebKit side to influence that.
* Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp:
(WebKit::XDGDBusProxy::accessibilityProxy):
Canonical link: https://commits.webkit.org/280770@main
Canonical link: https://commits.webkit.org/274313.311@webkitglib/2.44
Commit: f72290bf2fb0bec419e7c9383e5a68b47ed09832
https://github.com/WebKit/WebKit/commit/f72290bf2fb0bec419e7c9383e5a68b47ed09832
Author: Philippe Normand <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp
M
Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp
M Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.h
M
Source/WebCore/platform/mediastream/gstreamer/RealtimeOutgoingMediaSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 279570@main (ddfc6ce0fa86).
https://bugs.webkit.org/show_bug.cgi?id=274825
[GStreamer][MediaStream] Stream collection fixes
https://bugs.webkit.org/show_bug.cgi?id=274825
Reviewed by Xabier Rodriguez-Calvar.
Our MediaStream source element answers to GST_QUERY_SELECTABLE queries but
until this patch it
wasn't sending collection events on its pad(s). It still worked by luck in
GStreamer versions older
than 1.25/1.26, decodebin3 would still create a parsebin internally.
*
Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:
(webkitMediaStreamSrcEnsureStreamCollection):
(webkitMediaStreamSrcPostStreamCollection):
(webkitMediaStreamSrcAddPad):
(webkitMediaStreamSrcPadProbeCb):
(webkitMediaStreamSrcAddTrack):
(ProbeData::ProbeData): Deleted.
Canonical link: https://commits.webkit.org/279570@main
Canonical link: https://commits.webkit.org/274313.312@webkitglib/2.44
Commit: aa46101021f259803ddcd1b6235ef6367a88fd01
https://github.com/WebKit/WebKit/commit/aa46101021f259803ddcd1b6235ef6367a88fd01
Author: Philippe Normand <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 279567@main (4b149650aebe).
https://bugs.webkit.org/show_bug.cgi?id=274893
[GStreamer][MediaRecorder] Pipeline remains in global registry if
stopRecording is called
https://bugs.webkit.org/show_bug.cgi?id=274893
Reviewed by Xabier Rodriguez-Calvar.
Clearing the GStreamer pipeline without un-registering it from the global
registry would result in a
memory leak.
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp:
(WebCore::MediaRecorderPrivateBackend::stopRecording):
Canonical link: https://commits.webkit.org/279567@main
Canonical link: https://commits.webkit.org/274313.313@webkitglib/2.44
Commit: 28ee9f4373b72967a48cf674f9b987214f9dce5d
https://github.com/WebKit/WebKit/commit/28ee9f4373b72967a48cf674f9b987214f9dce5d
Author: Carlos Bentzen <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebCore/Modules/mediastream/PeerConnectionBackend.cpp
M Source/WebCore/Modules/mediastream/PeerConnectionBackend.h
M Source/WebCore/platform/mediastream/RTCRtpTransceiverDirection.h
Log Message:
-----------
Cherry-pick 279742@main (4d1937351919).
https://bugs.webkit.org/show_bug.cgi?id=275146
[WebRTC] Add debug logging of TransceiverStates
https://bugs.webkit.org/show_bug.cgi?id=275146
Reviewed by Philippe Normand.
Add debug logging of TransceiverStates, to aid debugging while moving
the GStreamer backend out of m_pendingTrackEvents in PeerConnectionBackend.
* Source/WebCore/Modules/mediastream/PeerConnectionBackend.cpp:
(WebCore::PeerConnectionBackend::setLocalDescriptionSucceeded):
(WebCore::PeerConnectionBackend::setRemoteDescriptionSucceeded):
(WebCore::toJSONObject):
(WebCore::toJSONArray):
(WebCore::toJSONString):
(WTF::LogArgument<WebCore::PeerConnectionBackend::TransceiverState>::toString):
(WTF::LogArgument<WebCore::PeerConnectionBackend::TransceiverStates>::toString):
* Source/WebCore/Modules/mediastream/PeerConnectionBackend.h:
(WebCore::PeerConnectionBackend::DescriptionStates::isolatedCopy):
* Source/WebCore/platform/mediastream/RTCRtpTransceiverDirection.h:
Canonical link: https://commits.webkit.org/279742@main
Canonical link: https://commits.webkit.org/274313.314@webkitglib/2.44
Commit: 55a685f16ce324b1c1aaabcae77d7bfbfbb054d4
https://github.com/WebKit/WebKit/commit/55a685f16ce324b1c1aaabcae77d7bfbfbb054d4
Author: Carlos Bentzen <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
A LayoutTests/webrtc/msid-setCodecPreferences-expected.txt
A LayoutTests/webrtc/msid-setCodecPreferences.html
M
Source/WebCore/Modules/mediastream/gstreamer/GStreamerRtpTransceiverBackend.cpp
Log Message:
-----------
Cherry-pick 279746@main (6d7fa27729b7).
https://bugs.webkit.org/show_bug.cgi?id=275157
[GStreamer][WebRTC] Missing a=msid in offer after setting codec preferences
https://bugs.webkit.org/show_bug.cgi?id=275157
Reviewed by Philippe Normand.
When setting codec preferences on GstWebRTCRTPTransceiver, the caps object
did not contain an "a-msid" field, which causes the offer created by the
webrtcbin containing that transceiver to not include an `a=msid` line for
it.
The issue is fixed by reusing the `a-msid` field from the pre-existent
codec preference, if one exists.
* LayoutTests/webrtc/msid-setCodecPreferences-expected.txt: Added.
* LayoutTests/webrtc/msid-setCodecPreferences.html: Added.
*
Source/WebCore/Modules/mediastream/gstreamer/GStreamerRtpTransceiverBackend.cpp:
(WebCore::getMsidFromCurrentCodecPreferences):
(WebCore::GStreamerRtpTransceiverBackend::setCodecPreferences):
Canonical link: https://commits.webkit.org/279746@main
Canonical link: https://commits.webkit.org/274313.315@webkitglib/2.44
Commit: d6ce942513281221ee709fdb229b7eceef040689
https://github.com/WebKit/WebKit/commit/d6ce942513281221ee709fdb229b7eceef040689
Author: Michael Catanzaro <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M LayoutTests/loader/stateobjects/pushstate-size-expected.txt
M LayoutTests/loader/stateobjects/pushstate-size-iframe-expected.txt
M Source/WebCore/history/HistoryItem.cpp
M Source/WebCore/history/HistoryItem.h
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/HistoryController.cpp
M Source/WebCore/loader/HistoryController.h
M Source/WebCore/page/History.cpp
M Source/WebCore/page/History.h
M Source/WebCore/page/History.idl
M Source/WebKit/Shared/WebBackForwardListItem.h
M Source/WebKit/UIProcess/API/C/WKBackForwardListItemRef.cpp
M Source/WebKit/UIProcess/API/C/WKBackForwardListItemRef.h
M Source/WebKit/UIProcess/API/Cocoa/WKBackForwardListItem.h
M Source/WebKit/UIProcess/API/Cocoa/WKBackForwardListItem.mm
M Source/WebKit/UIProcess/API/glib/WebKitBackForwardListItem.cpp
M Source/WebKit/UIProcess/API/glib/WebKitBackForwardListItem.h.in
M Source/WebKit/WebProcess/WebCoreSupport/SessionStateConversion.cpp
M Source/WebKitLegacy/mac/History/HistoryPropertyList.mm
M Source/WebKitLegacy/mac/History/WebHistory.mm
M Source/WebKitLegacy/mac/History/WebHistoryItem.mm
M Source/WebKitLegacy/mac/History/WebHistoryItemInternal.h
M Source/WebKitLegacy/mac/WebCoreSupport/WebFrameLoaderClient.mm
M Tools/MiniBrowser/gtk/BrowserWindow.c
M Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm
M Tools/TestWebKitAPI/Tests/WebKitGLib/TestBackForwardList.cpp
Log Message:
-----------
Revert "Ignore the “title” argument to
history.pushState()/history.replaceState()"
This reverts commit 4ef4b65d33f45734ad3c6cbc7f2fe0dda17051bc.
For context, see: https://github.com/WebKit/WebKit/pull/29643
Canonical link: https://commits.webkit.org/274313.316@webkitglib/2.44
Commit: 49b43b599a81d849875d7dca99a6e6460306af62
https://github.com/WebKit/WebKit/commit/49b43b599a81d849875d7dca99a6e6460306af62
Author: Xabier Rodriguez-Calvar <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
A
LayoutTests/media/media-source/media-source-seek-back-after-ended-expected.txt
A LayoutTests/media/media-source/media-source-seek-back-after-ended.html
M
Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp
Log Message:
-----------
Cherry-pick 279901@main (d36ed108e92f).
https://bugs.webkit.org/show_bug.cgi?id=275104
[MSE][GStreamer] allow fallback to seeked position on seek finish
https://bugs.webkit.org/show_bug.cgi?id=275104
Reviewed by Philippe Normand.
MediaPlayerPrivateGStreamer may report incorrect position (last cached)
immediately after seek. This can happen when
didPreroll is called on async-done with pipeline still in async transition
to playing state: current: PAUSED, pending:
PLAYING, result: ASYNC. r277541 disables querying position from the sinks
in this case resulting in last cached
value (before seek) to be returned. Which confuses some tests from YouTube
WV SFR/HFR suite, and makes it trigger
multiple seeks one after another.
The proposed change works around the problem by allowing fall back to last
seeked position until pipeline preroll
completes. Similar to MediaPlayerPrivateGStreamer::finishSeek().
Patch by Eugene Mutavchi <[email protected]>.
*
LayoutTests/media/media-source/media-source-seek-back-after-ended-expected.txt:
Added.
* LayoutTests/media/media-source/media-source-seek-back-after-ended.html:
Added.
* LayoutTests/platform/mac-wk1/TestExpectations:
*
Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp:
(WebCore::MediaPlayerPrivateGStreamerMSE::didPreroll):
Canonical link: https://commits.webkit.org/279901@main
Canonical link: https://commits.webkit.org/274313.317@webkitglib/2.44
Commit: 38145711a5fb1d32b64ed2ca7314fe36c6c9c264
https://github.com/WebKit/WebKit/commit/38145711a5fb1d32b64ed2ca7314fe36c6c9c264
Author: Philippe Normand <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebCore/platform/gstreamer/GStreamerElementHarness.cpp
Log Message:
-----------
Cherry-pick 279942@main (2d3841081a44).
https://bugs.webkit.org/show_bug.cgi?id=275205
[GStreamer] Crash in WebCore::VideoFrameGStreamer::createWrappedSample when
used by ImageDecoderGStreamer
https://bugs.webkit.org/show_bug.cgi?id=275205
Reviewed by Xabier Rodriguez-Calvar.
The issue here was that events were not correctly dispatched in nested
GStreamer element harnesses,
leading to situations where a video decoder would receive an audio caps
event, for instance. The VA
and libav decoders cope well with that situation, but the openh264 decoder
just accepted those audio
caps (which is a bug in that decoder).
The solution is to pass events from upstream to downstream harness, if
there is one. That's how
samples are also handled.
* Source/WebCore/platform/gstreamer/GStreamerElementHarness.cpp:
(WebCore::GStreamerElementHarness::Stream::Stream):
Canonical link: https://commits.webkit.org/279942@main
Canonical link: https://commits.webkit.org/274313.318@webkitglib/2.44
Commit: a9adbc01b6feb0652759c7e9dc7027c18ba34b72
https://github.com/WebKit/WebKit/commit/a9adbc01b6feb0652759c7e9dc7027c18ba34b72
Author: Michael Catanzaro <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WTF/wtf/UniStdExtras.h
M Source/WTF/wtf/playstation/UniStdExtrasPlayStation.cpp
M Source/WTF/wtf/unix/UniStdExtrasUnix.cpp
M Source/WebKit/Platform/IPC/unix/ConnectionUnix.cpp
Log Message:
-----------
Cherry-pick 280858@main (23af623a3a7e).
https://bugs.webkit.org/show_bug.cgi?id=275690
[WPE][GTK] IPC socket should use SOCK_CLOEXEC on Linux
https://bugs.webkit.org/show_bug.cgi?id=275690
Reviewed by Carlos Garcia Campos.
Instead of creating the IPC socket without CLOEXEC and then setting it
afterwards if requested, instead create the socket with CLOEXEC and
unset it afterwards if not requested. This closes the race window where
the socket may leak into a subprocess spawned by another thread (which
seems unlikely, but you never know what applications will do).
In practice, this ensures the server socket will never leak to a
subprocess. The client socket might still get leaked because CLOEXEC has
to get unset at some point for the child process to receive the socket.
* Source/WTF/wtf/UniStdExtras.h:
* Source/WTF/wtf/playstation/UniStdExtrasPlayStation.cpp:
(WTF::unsetCloseOnExec):
* Source/WTF/wtf/unix/UniStdExtrasUnix.cpp:
(WTF::unsetCloseOnExec):
* Source/WebKit/Platform/IPC/unix/ConnectionUnix.cpp:
(IPC::createPlatformConnection):
Canonical link: https://commits.webkit.org/280858@main
Canonical link: https://commits.webkit.org/274313.319@webkitglib/2.44
Commit: e70730772e1cab669d426391a610584cb6194a93
https://github.com/WebKit/WebKit/commit/e70730772e1cab669d426391a610584cb6194a93
Author: Michael Catanzaro <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebKit/Platform/IPC/IPCUtilities.h
M Source/WebKit/Platform/IPC/unix/ConnectionUnix.cpp
M Source/WebKit/Shared/unix/AuxiliaryProcessMain.cpp
M Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp
M Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.h
M Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp
Log Message:
-----------
Cherry-pick 281488@main (c3c75352f0ee).
https://bugs.webkit.org/show_bug.cgi?id=262794
[WPE][GTK] Web process cache suspend/resume does not work,
WebProcessProxy::processIdentifier is not the pid of the actual web process
https://bugs.webkit.org/show_bug.cgi?id=262794
Reviewed by Carlos Garcia Campos.
We'll use Unix credentials to send the actual pid of the child process
to the parent process.
This could be done using the WebKit IPC connection, but the code is
much simpler if we create a separate socket for this.
* Source/WebKit/Platform/IPC/IPCUtilities.h:
* Source/WebKit/Platform/IPC/unix/ConnectionUnix.cpp:
(IPC::createPlatformConnection):
(IPC::sendPIDToPeer):
(IPC::readPIDFromPeer):
* Source/WebKit/Shared/unix/AuxiliaryProcessMain.cpp:
(WebKit::AuxiliaryProcessMainCommon::parseCommandLine):
* Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp:
(WebKit::flatpakSpawn):
* Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.h:
* Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:
(WebKit::ProcessLauncher::launchProcess):
Canonical link: https://commits.webkit.org/281488@main
Canonical link: https://commits.webkit.org/274313.320@webkitglib/2.44
Commit: 4696320dd4a06afb63c0c49694629707fc2333ec
https://github.com/WebKit/WebKit/commit/4696320dd4a06afb63c0c49694629707fc2333ec
Author: Philippe Normand <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerVideoSinkCommon.cpp
Log Message:
-----------
Cherry-pick 280210@main (9d5844679af8).
https://bugs.webkit.org/show_bug.cgi?id=253807
[GTK][GStreamer] VA+DMABuf videos flicker
https://bugs.webkit.org/show_bug.cgi?id=253807
Reviewed by Xabier Rodriguez-Calvar.
By requesting a video frame allocation pool containing at least 3 frames,
the risks of flickering
when rendering should be reduced.
* Source/WebCore/platform/graphics/gstreamer/GStreamerVideoSinkCommon.cpp:
(WebKitVideoSinkProbe::doProbe):
Canonical link: https://commits.webkit.org/280210@main
Canonical link: https://commits.webkit.org/274313.321@webkitglib/2.44
Commit: eb64621c5a4f923c35630668e9ad81326636a7d1
https://github.com/WebKit/WebKit/commit/eb64621c5a4f923c35630668e9ad81326636a7d1
Author: Alicia Boya Garcia <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 276341@main (b4ac73768e74).
https://bugs.webkit.org/show_bug.cgi?id=270980
[MSE][GStreamer] Do more pipeline dumps in WebKitMediaSrc
https://bugs.webkit.org/show_bug.cgi?id=270980
Reviewed by Philippe Normand.
This patch adds more points where, if requested,
WebKitMediaSourceGStreamer will dump the playback pipeline.
It also refactors pipeline dumping into a separate function for improved
clarity and code reuse.
Pipeline dumps that were produced before by WebKitMediaSourceGStreamer:
- playback-pipeline-before-playback-{trackId}
- playback-pipeline-pushing-buffer-failed-{trackId}
Pipeline dumps that are produced after the patch:
- playback-pipeline-{trackId}-first-frame-before
- playback-pipeline-{trackId}-first-frame-after
- playback-pipeline-{trackId}-pushing-buffer-failed
- playback-pipeline-{trackId}-flush-start-before
- playback-pipeline-{trackId}-flush-start-after
- playback-pipeline-{trackId}-flush-stop-before
- playback-pipeline-{trackId}-flush-stop-after
Track ID has also been moved left in the name to bring attention to it.
*
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
(dumpPipeline):
(webKitMediaSrcLoop):
(webKitMediaSrcStreamFlush):
Canonical link: https://commits.webkit.org/276341@main
Canonical link: https://commits.webkit.org/274313.322@webkitglib/2.44
Commit: e0430b6972f1e94a87c76500564411a252693a29
https://github.com/WebKit/WebKit/commit/e0430b6972f1e94a87c76500564411a252693a29
Author: Philippe Normand <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 280297@main (0b3e3c5ec50b).
https://bugs.webkit.org/show_bug.cgi?id=275778
[GStreamer][MSE] Improved error handling in webkitmediasrc
https://bugs.webkit.org/show_bug.cgi?id=275778
Reviewed by Alicia Boya Garcia.
If we fail to push a buffer downstream we should post an error on the bus,
GST_ELEMENT_ERROR takes
care of that. In that case the error message will be handled in the player,
which will also dump the
pipeline graph, so there is no need to do that anymore from the source
element.
Driving-by, the pipeline dumps generated by webkitmediasrc are now named
according to the pipeline
they belong to, instead of hardcoding "playback-pipeline".
*
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
(dumpPipeline):
(webKitMediaSrcLoop):
Canonical link: https://commits.webkit.org/280297@main
Canonical link: https://commits.webkit.org/274313.323@webkitglib/2.44
Commit: 2eb2905cf2cd7ab16e1779453e0e7d7ea77f9f42
https://github.com/WebKit/WebKit/commit/2eb2905cf2cd7ab16e1779453e0e7d7ea77f9f42
Author: Philippe Normand <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebKit/gtk/gtk3-webkitgtk.toml.in
M Source/WebKit/gtk/gtk4-webkitgtk.toml.in
M Source/WebKit/gtk/webkitgtk-web-process-extension.toml.in
M Source/WebKit/wpe/wpe-web-process-extension.toml.in
M Source/WebKit/wpe/wpewebkit.toml.in
Log Message:
-----------
Cherry-pick 280572@main (6a465d3ecf85).
https://bugs.webkit.org/show_bug.cgi?id=276119
[WPE][GTK] Source links in generated API documentation are incorrect
https://bugs.webkit.org/show_bug.cgi?id=276119
Reviewed by Michael Catanzaro.
gi-docgen strips the last URL path component not ending with a slash,
apparently. So the source
links were missing the "main" part.
* Source/WebKit/gtk/gtk3-webkitgtk.toml.in:
* Source/WebKit/gtk/gtk4-webkitgtk.toml.in:
* Source/WebKit/gtk/webkitgtk-web-process-extension.toml.in:
* Source/WebKit/wpe/wpe-web-process-extension.toml.in:
* Source/WebKit/wpe/wpewebkit.toml.in:
Canonical link: https://commits.webkit.org/280572@main
Canonical link: https://commits.webkit.org/274313.324@webkitglib/2.44
Commit: a81b084a83036d43fa3efc27eb4f919326df2d32
https://github.com/WebKit/WebKit/commit/a81b084a83036d43fa3efc27eb4f919326df2d32
Author: Roope Salmi <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebKit/UIProcess/gtk/PointerLockManager.cpp
M Source/WebKit/UIProcess/gtk/PointerLockManager.h
M Source/WebKit/UIProcess/gtk/PointerLockManagerX11.cpp
M Source/WebKit/UIProcess/gtk/PointerLockManagerX11.h
Log Message:
-----------
Cherry-pick 280623@main (637888b2d2a3).
https://bugs.webkit.org/show_bug.cgi?id=273876
[GTK] Fix pointer lock on X11
https://bugs.webkit.org/show_bug.cgi?id=273876
Reviewed by Carlos Garcia Campos.
The XGrabPointer call was returning AlreadyGrabbed. This is apparently
because there is an active passive grab when the mouse is pressed down,
that comes via X Input Extensions (XI2) and not X Core. The XGrabPointer
implementation returns AlreadyGrabbed when the "grabtype" differs, i.e.
"XI" or "CORE". The passive grab may have changed into a touch grab at
some point, which goes through XI2.
My solution is to call XUngrabPointer before trying to grab it.
Fixing this uncovered a secondary issue: the coordinates given to
XWarpPointer were incorrect. I get the actual root-relative coordinates
with XQueryPointer during lock() instead of trying to convert from
m_initialPoint. (That would require handling the offset of the widget
inside the window and DPI scaling.)
I then got a continuous stream of MouseEvents even when the mouse was
stationary due to float rounding differences. In didReceiveMotionEvent,
I added a check that the delta coordinates are non-zero when rounded to
integers, so no events are sent with delta 0.
There are slight errors and differences in how movementX/Y values behave
when locked vs unlocked. These should be addressed separately.
Tested manually with -DUSE_GTK4=ON,OFF, GDK_SCALE=1,2.
* Source/WebKit/UIProcess/gtk/PointerLockManager.cpp:
(WebKit::PointerLockManager::handleMotion):
* Source/WebKit/UIProcess/gtk/PointerLockManager.h:
* Source/WebKit/UIProcess/gtk/PointerLockManagerX11.cpp:
(WebKit::PointerLockManagerX11::lock):
(WebKit::PointerLockManagerX11::didReceiveMotionEvent):
* Source/WebKit/UIProcess/gtk/PointerLockManagerX11.h:
Canonical link: https://commits.webkit.org/280623@main
Canonical link: https://commits.webkit.org/274313.325@webkitglib/2.44
Commit: 5c1d0983fcdafff05a7c7b295c213dcd331df333
https://github.com/WebKit/WebKit/commit/5c1d0983fcdafff05a7c7b295c213dcd331df333
Author: Enrique Ocaña González <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 280813@main (04cc4a4e2fc2).
https://bugs.webkit.org/show_bug.cgi?id=276251
[MSE][GStreamer] block data flow until source pad is exposed
https://bugs.webkit.org/show_bug.cgi?id=276251
Reviewed by Xabier Rodriguez-Calvar.
In WebKitMediaSrc, there could be a race between main thread (linking
typefind element, see gsturisourcebin.c:setup_typefind) and streaming
thread (pushing data). webKitMediaSrcLoop does wait for source pad to
linked. However, there is no guarantee that peer pad is already active
at that point. This may lead to data loss while peer the pad is being
activated.
This change blocks downstream flow during pad addition, allowing
urisourcebin to link/activate typefind sink pad.
See: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1355
Original patch by Eugene Mutavchi <[email protected]>.
*
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
(webKitMediaSrcEmitStreams): Add blocking probes to the Streams Pads, which
will be removed after the pad has been added to the element.
Canonical link: https://commits.webkit.org/280813@main
Canonical link: https://commits.webkit.org/274313.326@webkitglib/2.44
Commit: 1e175bbc401993af4b10841bcd8d110a5a84ae69
https://github.com/WebKit/WebKit/commit/1e175bbc401993af4b10841bcd8d110a5a84ae69
Author: Michael Catanzaro <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebCore/platform/glib/UserAgentQuirks.cpp
Log Message:
-----------
Cherry-pick 281402@main (5965f597b3e1).
https://bugs.webkit.org/show_bug.cgi?id=277144
[WPE][GTK] Unsupported browser warning on Google Docs
https://bugs.webkit.org/show_bug.cgi?id=277144
Reviewed by Carlos Garcia Campos.
Updating the Chrome quirk should fix this bug. We can also update the
Firefox quirk for good measure. Let's try to stay ahead of the game by
using an unsubtle high version number.
* Source/WebCore/platform/glib/UserAgentQuirks.cpp:
(WebCore::UserAgentQuirks::stringForQuirk):
Canonical link: https://commits.webkit.org/281402@main
Canonical link: https://commits.webkit.org/274313.327@webkitglib/2.44
Commit: 875fd605bd852ac41ca90169feb5fb267cd8ab8a
https://github.com/WebKit/WebKit/commit/875fd605bd852ac41ca90169feb5fb267cd8ab8a
Author: Philippe Normand <[email protected]>
Date: 2024-07-30 (Tue, 30 Jul 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
Log Message:
-----------
Cherry-pick 280808@main (5a41131cab31).
https://bugs.webkit.org/show_bug.cgi?id=276296
[GStreamer] Paused pipelines accumulate when scrolling on Reddit pages with
many videos
https://bugs.webkit.org/show_bug.cgi?id=276296
Reviewed by Xabier Rodriguez-Calvar.
Dispose the GStreamer pipeline if the destination
TextureMapperPlatformLayerProxy becomes inactive,
meaning that either the compositor is gone or the target layer no longer
exists.
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::~MediaPlayerPrivateGStreamer):
(WebCore::MediaPlayerPrivateGStreamer::tearDown):
(WebCore::MediaPlayerPrivateGStreamer::isPipelineWaitingPreroll const):
(WebCore::MediaPlayerPrivateGStreamer::buffered const):
(WebCore::MediaPlayerPrivateGStreamer::pausedTimerFired):
(WebCore::MediaPlayerPrivateGStreamer::pushTextureToCompositor):
(WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):
(WebCore::MediaPlayerPrivateGStreamer::setVisibleInViewport):
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
Canonical link: https://commits.webkit.org/280808@main
Canonical link: https://commits.webkit.org/274313.328@webkitglib/2.44
Compare: https://github.com/WebKit/WebKit/compare/cf9ddb5095a8...875fd605bd85
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
