Branch: refs/heads/webkitglib/2.44
Home: https://github.com/WebKit/WebKit
Commit: 21a14e254586234eddaf9b091b9e61ee4116f566
https://github.com/WebKit/WebKit/commit/21a14e254586234eddaf9b091b9e61ee4116f566
Author: Xabier Rodriguez-Calvar <calva...@igalia.com>
Date: 2024-04-27 (Sat, 27 Apr 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 274730@main (f270bdb7b34c).
https://bugs.webkit.org/show_bug.cgi?id=263317
[MSE][GStreamer] Pause after seek is not working
https://bugs.webkit.org/show_bug.cgi?id=263317
Reviewed by Philippe Normand.
So far we are just asking the pipeline if we were paused or not but that
does not work when the pipeline is
transitioning or seeking. That creates desynchronization between the media
element and the player. We now consider the
pipeline in the final state while it is transitioning, as it can handle
other requests while at it.
We also need to force ready state change when the pipeline finishes the
state change to paused or playing because the
player will report state changes sooner.
This changes won't apply to MediaStream because the dynamics of prerolling
are much different.
Fly by style change in isPipelineSeeking.
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::isPipelineSeeking const):
(WebCore::MediaPlayerPrivateGStreamer::paused const):
(WebCore::MediaPlayerPrivateGStreamer::updateStates):
Canonical link: https://commits.webkit.org/274730@main
Canonical link: https://commits.webkit.org/274313.169@webkitglib/2.44
Commit: abe23c2400b65f81f755a2725248642a9fda52b3
https://github.com/WebKit/WebKit/commit/abe23c2400b65f81f755a2725248642a9fda52b3
Author: Przemyslaw Gorszkowski <pgorszkow...@igalia.com>
Date: 2024-04-27 (Sat, 27 Apr 2024)
Changed paths:
M Source/WebCore/page/UserScript.cpp
M Source/WebCore/page/UserStyleSheet.cpp
Log Message:
-----------
Cherry-pick 277533@main (4e328a1f0c16).
https://bugs.webkit.org/show_bug.cgi?id=272666
Fix potential unified build error
https://bugs.webkit.org/show_bug.cgi?id=272666
Reviewed by Adrian Perez de Castro.
The problem is the same name of global static function in two cpp files.
This change resolves potential compiler error in unified build.
* Source/WebCore/page/UserScript.cpp:
(WebCore::generateUserScriptUniqueURL):
(WebCore::UserScript::UserScript):
(WebCore::generateUniqueURL): Deleted.
* Source/WebCore/page/UserStyleSheet.cpp:
(WebCore::generateUserStyleUniqueURL):
(WebCore::UserStyleSheet::UserStyleSheet):
(WebCore::generateUniqueURL): Deleted.
Canonical link: https://commits.webkit.org/277533@main
Canonical link: https://commits.webkit.org/274313.170@webkitglib/2.44
Commit: 66fe4f6f1ede0cdabb77987423f8de3085e03c93
https://github.com/WebKit/WebKit/commit/66fe4f6f1ede0cdabb77987423f8de3085e03c93
Author: Xabier Rodriguez-Calvar <calva...@igalia.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 275037@main (3ab7997af7e5).
https://bugs.webkit.org/show_bug.cgi?id=269782
[GStreamer] Fix audio sink detection in custom platforms
https://bugs.webkit.org/show_bug.cgi?id=269782
Reviewed by Philippe Normand.
Sometimes we can get a message from a new audio sink that we should store
as such even when we already have one.
Based on a patch by Pawel Lampe <pawel.la...@gmail.com>.
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::handleMessage):
Canonical link: https://commits.webkit.org/275037@main
Canonical link: https://commits.webkit.org/274313.171@webkitglib/2.44
Commit: 1c9023f4037fb4eda161b557c1b7374b313abaee
https://github.com/WebKit/WebKit/commit/1c9023f4037fb4eda161b557c1b7374b313abaee
Author: Charlie Wolfe <charl...@apple.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebFrame.cpp
Log Message:
-----------
Cherry-pick 275113@main (53a866856e70).
https://bugs.webkit.org/show_bug.cgi?id=269829
Remove the owner element null check in WebFrame::parentFrame()
https://bugs.webkit.org/show_bug.cgi?id=269829
rdar://123343035
Reviewed by Alex Christensen.
I tried to fix a null pointer crash in 274274@main with Site Isolation
enabled but didn’t remove this
null check. If the parent frame is being hosted in another process the
owner element will always be null.
* Source/WebKit/WebProcess/WebPage/WebFrame.cpp:
(WebKit::WebFrame::parentFrame const):
Canonical link: https://commits.webkit.org/275113@main
Canonical link: https://commits.webkit.org/274313.172@webkitglib/2.44
Commit: 3478c0c5b6423f73b6077330e83dcb212cf791d2
https://github.com/WebKit/WebKit/commit/3478c0c5b6423f73b6077330e83dcb212cf791d2
Author: Aditya Keerthi <akeer...@apple.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/FullscreenManager.cpp
M Source/WebCore/dom/FullscreenManager.h
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/ios/FullscreenLayoutParameters.mm
R Tools/TestWebKitAPI/Tests/ios/FullscreenOverriddenLayoutParameters.mm
Log Message:
-----------
Cherry-pick 275115@main (e680442311f3).
https://bugs.webkit.org/show_bug.cgi?id=269795
REGRESSION: Scrolling down and attempting to fullscreen video on
twitter.com displays the feed
https://bugs.webkit.org/show_bug.cgi?id=269795
rdar://122981183
Reviewed by Jer Noble.
In order for element fullscreen to behave correctly, sites rely on the
following
invariants:
1. "fullscreenchange" is fired before "resize".
2. The values of viewport properties during "fullscreenchange" match the
fullscreen size.
Twitter relies on (1), as they teardown the video player if "resize" occurs
during the transition into fullscreen.
270199@main broke two things:
1. The ordering of "fullscreenchange" and "resize" events when entering
fullscreen on iPadOS.
2. The values of viewport properties during the "fullscreenchange" event on
visionOS.
(1) went undetected for a long time, because at first, the effect was not
this
bug, but a crash, fixed in 273885@main.
272752@main fixed (2), but also introduced (1) on visionOS.
To the invariant mentioned above is true, fix by adding logic which ensures
"resize" is dispatched after "fullscreenchange".
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setNeedsDOMWindowResizeEvent):
(WebCore::Document::setNeedsVisualViewportResize):
* Source/WebCore/dom/FullscreenManager.cpp:
(WebCore::FullscreenManager::setAnimatingFullscreen):
(WebCore::FullscreenManager::addPendingScheduledResize):
* Source/WebCore/dom/FullscreenManager.h:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/ios/FullscreenLayoutParameters.mm: Renamed from
Tools/TestWebKitAPI/Tests/ios/FullscreenOverriddenLayoutParameters.mm.
(TestWebKitAPI::TEST):
Canonical link: https://commits.webkit.org/275115@main
Canonical link: https://commits.webkit.org/274313.173@webkitglib/2.44
Commit: f65fd5872603c1efab80844827cd1fe6c5accaa5
https://github.com/WebKit/WebKit/commit/f65fd5872603c1efab80844827cd1fe6c5accaa5
Author: Rob Buis <rb...@igalia.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
A
LayoutTests/platform/glib/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt
A
LayoutTests/platform/ios/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt
M LayoutTests/platform/mac-sonoma-wk2-lbse-text/TestExpectations
A
LayoutTests/platform/mac-sonoma-wk2-lbse-text/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt
A
LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.png
A
LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt
A
LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox.xhtml
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
Log Message:
-----------
Cherry-pick 275117@main (c443c971c715).
https://bugs.webkit.org/show_bug.cgi?id=269234
Fix custom/pattern-userSpaceOnUse-userToBaseTransform.xhtml
https://bugs.webkit.org/show_bug.cgi?id=269234
Reviewed by Nikolas Zimmermann.
When determining RenderSVGRoot as root layer we also calculate
any padding/border values as part of offsetFromAncestor, this
means for patterns painting would be wrongly offset for pattern
content. Instead, use the RenderSVGRoot, viewport as root layer
which discards any border/padding for the pattern content painting.
*
LayoutTests/platform/glib/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt:
Added.
*
LayoutTests/platform/ios/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt:
Added.
* LayoutTests/platform/mac-sonoma-wk2-lbse-text/TestExpectations:
*
LayoutTests/platform/mac-sonoma-wk2-lbse-text/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt:
Added.
*
LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.png:
Added.
*
LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox-expected.txt:
Added.
*
LayoutTests/svg/custom/pattern-userSpaceOnUse-userToBaseTransform-with-viewBox.xhtml:
Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::paintSVGResourceLayer):
(WebCore::RenderLayer::enclosingSVGRootLayer const): Deleted.
* Source/WebCore/rendering/RenderLayer.h:
Canonical link: https://commits.webkit.org/275117@main
Canonical link: https://commits.webkit.org/274313.174@webkitglib/2.44
Commit: 61221113c277e7811d88a33237b5693cf21378fb
https://github.com/WebKit/WebKit/commit/61221113c277e7811d88a33237b5693cf21378fb
Author: Qianlang Chen <qianlangc...@apple.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
M Source/WebInspectorUI/UserInterface/Base/Main.js
M Source/WebInspectorUI/UserInterface/Protocol/InspectorFrontendAPI.js
M Source/WebInspectorUI/UserInterface/Views/LogContentView.js
Log Message:
-----------
Cherry-pick 275143@main (08a1f3998383).
https://bugs.webkit.org/show_bug.cgi?id=268882
Fix Web Inspector: Remember the message type selection in the Console tab
rdar://122924275
https://bugs.webkit.org/show_bug.cgi?id=268882
Reviewed by Devin Rousso.
When showing the the inspector's console using `WI.showConsole()`, the
caller can optionally pass in a `requestedScope` to control which levels
(AKA message types) to be filtered automatically when the Console tab
shows up. However, when `requestedScope` is falsy or left empty, it
always applies `WI.LogContentView.Scopes.All` instead, which
overrides the levels selected by default, which are read from local
settings when the scope bar is created at the inspector's startup.
This commit removes the forced application of `Scopes.All`, so when
`requestedScope` is left empty, the Console tab is shown with levels
unchanged, which is the expected behavior when launching the Console tab
through Develop -> Show JavaScript Console (or Option-Command-C).
This fix has one known side-effect: when an inspector tab does not
support split console view, pressing Esc will switch to the actual
Console tab instead. (The Settings tab is one example of such tab.)
This commit will make that also "remember" the previously selected
levels instead of deselecting back to just `Scopes.All`, which is
arguably the correct behavior anyway.
This commit also cleans up on how `requestedScope` gets passed in;
passing in as part of the `options` parameter allows callers of
`showConsole()` to self-document the usage `requestedScope`.
* Source/WebInspectorUI/UserInterface/Base/Main.js:
- Fix the bug.
- Adapt to the clean up for the `options` parameter.
* Source/WebInspectorUI/UserInterface/Protocol/InspectorFrontendAPI.js:
(InspectorFrontendAPI.showConsole):
- Adapt to the clean up for the `options` parameter.
* Source/WebInspectorUI/UserInterface/Views/LogContentView.js:
(WI.LogContentView.prototype._showConsoleTab):
- Adapt to the clean up for the `options` parameter.
Canonical link: https://commits.webkit.org/275143@main
Canonical link: https://commits.webkit.org/274313.175@webkitglib/2.44
Commit: cef9106fb47d708920a30fe87c13033e8f483a28
https://github.com/WebKit/WebKit/commit/cef9106fb47d708920a30fe87c13033e8f483a28
Author: Ahmad Saleem <ahmad.saleem792+git...@gmail.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
M Source/WebInspectorUI/UserInterface/Models/CSSKeywordCompletions.js
Log Message:
-----------
Cherry-pick 275160@main (d477c762a9ec).
https://bugs.webkit.org/show_bug.cgi?id=269889
Web Inspector: Add '*-conic-gradient' for autocompletion suggestion in
'background'
https://bugs.webkit.org/show_bug.cgi?id=269889
Reviewed by Timothy Hatcher.
This patch adds missing 'conic-gradient' and 'repeating-conic-gradient'
support in autocompletion for background since these properties
are supported as far back as 2018 with 204375@main.
* Source/WebInspectorUI/UserInterface/Models/CSSKeywordCompletions.js:
(background): Add 'conic-gradient()' and 'repeating-conic-gradient()'
Canonical link: https://commits.webkit.org/275160@main
Canonical link: https://commits.webkit.org/274313.176@webkitglib/2.44
Commit: 1a7ce9a4dd0bd2bab811a50f1cad907e71cb0c9c
https://github.com/WebKit/WebKit/commit/1a7ce9a4dd0bd2bab811a50f1cad907e71cb0c9c
Author: Philippe Normand <ph...@igalia.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
M
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/RealtimeIncomingAudioSourceLibWebRTC.cpp
Log Message:
-----------
Cherry-pick 275162@main (429961d17d20).
https://bugs.webkit.org/show_bug.cgi?id=269840
[LibWebRTC][GStreamer] Incoming audio stream clips and glitches
https://bugs.webkit.org/show_bug.cgi?id=269840
Reviewed by Xabier Rodriguez-Calvar.
Add audio meta to incoming audio buffers so that downstream converters
don't produce garbage.
*
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/RealtimeIncomingAudioSourceLibWebRTC.cpp:
(WebCore::RealtimeIncomingAudioSourceLibWebRTC::OnData):
Canonical link: https://commits.webkit.org/275162@main
Canonical link: https://commits.webkit.org/274313.177@webkitglib/2.44
Commit: 00bd6aeac161f301bfee3b6156aeb4ba7b72d006
https://github.com/WebKit/WebKit/commit/00bd6aeac161f301bfee3b6156aeb4ba7b72d006
Author: Philippe Normand <ph...@igalia.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
M
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp
Log Message:
-----------
Cherry-pick 275166@main (764cbc51fef5).
https://bugs.webkit.org/show_bug.cgi?id=269838
[LibWebRTC][GStreamer] Incoming H.264 stream parsing fails
https://bugs.webkit.org/show_bug.cgi?id=269838
Reviewed by Xabier Rodriguez-Calvar.
Workaround cases where the GStreamer LibWebRTC decoder is expected to
process frames with invalid
render time.
*
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp:
(WebCore::GStreamerVideoDecoder::GstDecoderFactory):
Canonical link: https://commits.webkit.org/275166@main
Canonical link: https://commits.webkit.org/274313.178@webkitglib/2.44
Commit: c65b681ebb984c3f6799c550bd995989bed2d39d
https://github.com/WebKit/WebKit/commit/c65b681ebb984c3f6799c550bd995989bed2d39d
Author: Rob Buis <rb...@igalia.com>
Date: 2024-04-30 (Tue, 30 Apr 2024)
Changed paths:
A
LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-expected.txt
A
LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-on-keydown-expected.txt
A
LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-on-keydown.html
A
LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options.html
M Source/WebCore/html/DataListSuggestionInformation.h
M Source/WebCore/html/HTMLDataListElement.cpp
M Source/WebCore/html/HTMLDataListElement.h
M Source/WebCore/html/TextFieldInputType.cpp
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/ios/WebDataListSuggestionsDropdownIOS.mm
Log Message:
-----------
Cherry-pick 274608@main (ba02cc6aade5).
https://bugs.webkit.org/show_bug.cgi?id=201121
Displayed datalist dropdown is out of sync with datalist options elements
after DOM update
https://bugs.webkit.org/show_bug.cgi?id=201121
Reviewed by Aditya Keerthi.
Adding datalist dropdown items by dynamically inserting options to the
datalist on keydown/input change
was not taking effect right away. To fix this, detect datalist DOM changes
through HTMLDataListElement::childrenChanged
and notify the corresponding input. This will eventually land in
TextFieldInputType::dataListMayHaveChanged which
now ends with trying to display the suggestions if the input is focused.
Note that here a new DataListSuggestionActivationType value
DataListMayHaveChanged is added to distinguish from
current usages (text changed, indicator/control clicked).
*
LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-expected.txt:
Added.
*
LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-on-keydown-expected.txt:
Added.
*
LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options-on-keydown.html:
Added.
*
LayoutTests/fast/forms/datalist/datalist-textinput-dynamically-add-options.html:
Added.
* Source/WebCore/html/DataListSuggestionInformation.h:
* Source/WebCore/html/HTMLDataListElement.cpp:
(WebCore::HTMLDataListElement::childrenChanged):
* Source/WebCore/html/HTMLDataListElement.h:
* Source/WebCore/html/TextFieldInputType.cpp:
(WebCore::TextFieldInputType::dataListMayHaveChanged):
(WebCore::TextFieldInputType::displaySuggestions):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/UIProcess/ios/WebDataListSuggestionsDropdownIOS.mm:
(-[WKDataListSuggestionsDropdown _displayWithActivationType:]):
Canonical link: https://commits.webkit.org/274608@main
Canonical link: https://commits.webkit.org/274313.179@webkitglib/2.44
Commit: e8ae6ff45a705838ab002a7fc8829312ffc4e320
https://github.com/WebKit/WebKit/commit/e8ae6ff45a705838ab002a7fc8829312ffc4e320
Author: Ryosuke Niwa <rn...@webkit.org>
Date: 2024-04-30 (Tue, 30 Apr 2024)
Changed paths:
A LayoutTests/fast/dom/datalist-children-changed-crash-expected.txt
A LayoutTests/fast/dom/datalist-children-changed-crash.html
M Source/WebCore/dom/ContainerNode.cpp
M Source/WebCore/html/HTMLDataListElement.cpp
Log Message:
-----------
Cherry-pick 275221@main (9a1d1c7db218).
https://bugs.webkit.org/show_bug.cgi?id=269959
HTMLDataListElement::childrenChanged doesn't call
HTMLElement::childrenChanged
https://bugs.webkit.org/show_bug.cgi?id=269959
<rdar://123388053>
Reviewed by Chris Dumez.
This can lead to an inconsistent state in DOM so call that.
* LayoutTests/fast/dom/datalist-children-changed-crash-expected.txt: Added.
* LayoutTests/fast/dom/datalist-children-changed-crash.html: Added.
* Source/WebCore/dom/ContainerNode.cpp:
(WebCore::ContainerNode::removeAllChildrenWithScriptAssertion): Added a
debug
assertion to catch a similar mistake in the future.
* Source/WebCore/html/HTMLDataListElement.cpp:
(WebCore::HTMLDataListElement::childrenChanged):
Canonical link: https://commits.webkit.org/275221@main
Canonical link: https://commits.webkit.org/274313.180@webkitglib/2.44
Commit: eef9441ffe42e5573ae7224e69d07deec66a301d
https://github.com/WebKit/WebKit/commit/eef9441ffe42e5573ae7224e69d07deec66a301d
Author: Philippe Normand <ph...@igalia.com>
Date: 2024-04-30 (Tue, 30 Apr 2024)
Changed paths:
M
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp
M
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoFrameLibWebRTC.cpp
M
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoFrameLibWebRTC.h
Log Message:
-----------
Cherry-pick 275226@main (277513e286a0).
https://bugs.webkit.org/show_bug.cgi?id=269903
[LibWebRTC][GStreamer] Clean-up GstSample ownership semantics in LibWebRTC
VideoFrame
https://bugs.webkit.org/show_bug.cgi?id=269903
Reviewed by Xabier Rodriguez-Calvar.
The sample reference can be moved to the VideoFrame.
*
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoDecoderFactory.cpp:
(WebCore::GStreamerVideoDecoder::pullSample):
*
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoFrameLibWebRTC.cpp:
(WebCore::convertGStreamerSampleToLibWebRTCVideoFrame):
(WebCore::GStreamerVideoFrameLibWebRTC::create):
*
Source/WebCore/platform/mediastream/libwebrtc/gstreamer/GStreamerVideoFrameLibWebRTC.h:
(WebCore::GStreamerVideoFrameLibWebRTC::GStreamerVideoFrameLibWebRTC):
Canonical link: https://commits.webkit.org/275226@main
Canonical link: https://commits.webkit.org/274313.181@webkitglib/2.44
Commit: cf8e66cdac79e66273712e88583669f6820ab9ae
https://github.com/WebKit/WebKit/commit/cf8e66cdac79e66273712e88583669f6820ab9ae
Author: Dana Estra <des...@apple.com>
Date: 2024-04-30 (Tue, 30 Apr 2024)
Changed paths:
M Source/WebCore/Modules/modern-media-controls/controls/button.js
Log Message:
-----------
Cherry-pick 275229@main (c67d585912b3).
https://bugs.webkit.org/show_bug.cgi?id=269951
Pause control does not work in in-window mode
https://bugs.webkit.org/show_bug.cgi?id=269951
rdar://122834226
Reviewed by Jer Noble.
This bug was caused by both our event handler for clicking on the pause
button
and youtube's event handler for clicking on the video both being activated,
causing the video to pause and then immediately be played again. To prevent
this, in our button's event handler we now call stopPropagation().
* Source/WebCore/Modules/modern-media-controls/controls/button.js:
(Button.prototype.handleEvent):
Canonical link: https://commits.webkit.org/275229@main
Canonical link: https://commits.webkit.org/274313.182@webkitglib/2.44
Commit: 72e431529386c9f361caf7f839d3e2d1a5f98aed
https://github.com/WebKit/WebKit/commit/72e431529386c9f361caf7f839d3e2d1a5f98aed
Author: Chris Dumez <cdu...@apple.com>
Date: 2024-04-30 (Tue, 30 Apr 2024)
Changed paths:
A LayoutTests/webaudio/getOutputTimestamp-expected.txt
A LayoutTests/webaudio/getOutputTimestamp.html
M Source/WebCore/platform/audio/AudioDestinationResampler.cpp
Log Message:
-----------
Cherry-pick 275237@main (33172dfe163a).
https://bugs.webkit.org/show_bug.cgi?id=264247
getOutputTimestamp() seems to use wrong time scale
https://bugs.webkit.org/show_bug.cgi?id=264247
rdar://118323705
Reviewed by Eric Carlson.
The time returned by getOutputTimestamp() was incorrectly divided by the
sample rate. Fix this so the value returned is correct and matches Chrome
and Firefox.
* LayoutTests/webaudio/getOutputTimestamp-expected.txt: Added.
* LayoutTests/webaudio/getOutputTimestamp.html: Added.
* Source/WebCore/platform/audio/AudioDestinationResampler.cpp:
(WebCore::AudioDestinationResampler::render):
Canonical link: https://commits.webkit.org/275237@main
Canonical link: https://commits.webkit.org/274313.183@webkitglib/2.44
Commit: f923d49e0af5b52b335ff49d6701fcbcae464fb7
https://github.com/WebKit/WebKit/commit/f923d49e0af5b52b335ff49d6701fcbcae464fb7
Author: Sosuke Suzuki <sosuke.suz...@dr-ubie.com>
Date: 2024-04-30 (Tue, 30 Apr 2024)
Changed paths:
A JSTests/stress/string-replace-regexp-deopt-lastindex.js
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
Log Message:
-----------
Cherry-pick 275255@main (3790f1e3cc0a).
https://bugs.webkit.org/show_bug.cgi?id=246274
[JSC] Don't optimize String.prototype.replace for RegExp searchValue with
non-numeric lastIndex.
https://bugs.webkit.org/show_bug.cgi?id=246274
Reviewed by Alexey Shvayka.
In DFGByteCodeParser, String.prototype.replace with a RegExp object as
searchValue is inlined into a StringReplace node.
So after DFG, lastIndex is no longer read and updated. Therefore,
searchValue.lastIndex.toString is no longer invoked.
This patch changes the code so that it doesn't inline if
searchValue.lastIndex isn't numeric.
https://tc39.es/ecma262/#sec-string.prototype.replace
* JSTests/stress/string-replace-regexp-deopt-lastindex.js: Added.
(shouldBe):
(foo.regexLastIndex.toString):
(foo):
* Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::addStringReplacePrimordialChecks):
Canonical link: https://commits.webkit.org/275255@main
Canonical link: https://commits.webkit.org/274313.184@webkitglib/2.44
Commit: 45a128ec1c19b8994372a1abb5a5555a2043d470
https://github.com/WebKit/WebKit/commit/45a128ec1c19b8994372a1abb5a5555a2043d470
Author: Jean-Yves Avenard <j...@apple.com>
Date: 2024-04-30 (Tue, 30 Apr 2024)
Changed paths:
A LayoutTests/media/media-source/media-managedmse-eviction-expected.txt
A LayoutTests/media/media-source/media-managedmse-eviction.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/graphics/SourceBufferPrivate.cpp
Log Message:
-----------
Cherry-pick 275306@main (19f884773fca).
https://bugs.webkit.org/show_bug.cgi?id=270034
[MSE] Media from the TimeRange containing currentTime can be evicted when
it shouldn't
https://bugs.webkit.org/show_bug.cgi?id=270034
rdar://problem/123556056
Reviewed by Eric Carlson.
We want none of the data contiguous from the currentTime to the next
discontinuity to be
evicted to ensure continuous playback.
This is inline with Google's proposal for having Eviction Policies.
The comments in the eviction code indicated as such, but a logic error
would have made
the end of the current range be truncated if it was followed by another
range
after a discontinuity.
* LayoutTests/media/media-source/media-managedmse-eviction-expected.txt:
Added.
* LayoutTests/media/media-source/media-managedmse-eviction.html: Added.
* LayoutTests/platform/glib/TestExpectations:
* Source/WebCore/platform/graphics/SourceBufferPrivate.cpp:
(WebCore::SourceBufferPrivate::evictFrames):
Canonical link: https://commits.webkit.org/275306@main
Canonical link: https://commits.webkit.org/274313.185@webkitglib/2.44
Commit: 5f382893b85e01690707fba11dd02878807725d8
https://github.com/WebKit/WebKit/commit/5f382893b85e01690707fba11dd02878807725d8
Author: Sihui Liu <sihui_...@apple.com>
Date: 2024-05-01 (Wed, 01 May 2024)
Changed paths:
M Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp
Log Message:
-----------
Cherry-pick 275364@main (fbc96c364894).
https://bugs.webkit.org/show_bug.cgi?id=270137
Add null check in SQLiteIDBBackingStore::getAllIndexRecords
https://bugs.webkit.org/show_bug.cgi?id=270137
rdar://113116109
Reviewed by Chris Dumez.
Crash traces indicate SQLiteIDBBackingStore may fail to find valid object
store for requested operation, so return error
instead of crashing network process in that case.
* Source/WebCore/Modules/indexeddb/server/SQLiteIDBBackingStore.cpp:
(WebCore::IDBServer::SQLiteIDBBackingStore::getRecord):
(WebCore::IDBServer::SQLiteIDBBackingStore::getAllObjectStoreRecords):
(WebCore::IDBServer::SQLiteIDBBackingStore::getAllIndexRecords):
Canonical link: https://commits.webkit.org/275364@main
Canonical link: https://commits.webkit.org/274313.186@webkitglib/2.44
Commit: fdf2beec03624c2101e4f89f8399ead9bfaf6c6c
https://github.com/WebKit/WebKit/commit/fdf2beec03624c2101e4f89f8399ead9bfaf6c6c
Author: Nicole Rosario <nicole_rosa...@apple.com>
Date: 2024-05-01 (Wed, 01 May 2024)
Changed paths:
A LayoutTests/ipc/send-ignored-network-message-expected.txt
A LayoutTests/ipc/send-ignored-network-message.html
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 275369@main (eaa2c46c3922).
https://bugs.webkit.org/show_bug.cgi?id=270006
ASSERT_WITH_SECURITY_IMPLICATION reached on Messages::NetworkProcess in
NetworkConnectionToWebProcess::didReceiveMessage()
https://bugs.webkit.org/show_bug.cgi?id=270006
rdar://123087621
Reviewed by Alex Christensen and Chris Dumez.
Replace assertions checking that `decoder.messageReceiverName() !=
Messages::NetworkProcess::messageReceiverName()` with MESSAGE_CHECK.
Network messages from the web content process are safely ignored
elsewhere already so the assert is not needed
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::didReceiveMessage):
(WebKit::NetworkConnectionToWebProcess::didReceiveSyncMessage):
Canonical link: https://commits.webkit.org/275369@main
Canonical link: https://commits.webkit.org/274313.187@webkitglib/2.44
Commit: a5e0fc2f4bda568b4d61f95b7d0ff99cb9d61067
https://github.com/WebKit/WebKit/commit/a5e0fc2f4bda568b4d61f95b7d0ff99cb9d61067
Author: Rob Buis <rb...@igalia.com>
Date: 2024-05-01 (Wed, 01 May 2024)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-flex-fraction-expected.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-flex-fraction.html
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
M Source/WebCore/rendering/RenderGrid.h
Log Message:
-----------
Cherry-pick 275376@main (dd25a04355e3).
https://bugs.webkit.org/show_bug.cgi?id=268874
Regression (Safari 17 vs 16.5, 261003@main): height collapsing on
auto-height image when container-type set on parent
https://bugs.webkit.org/show_bug.cgi?id=268874
Reviewed by Alan Baradlay.
In r261003 isComputingSizeOrInlineSizeContainment was used which did not
consider grid track sizing direction. Fix that
by using shouldCheckExplicitIntrinsicInnerLogicalSize which will take the
direction into account.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-flex-fraction-expected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-contain/contain-inline-size-flex-fraction.html:
Added.
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::IndefiniteSizeStrategy::findUsedFlexFraction const):
* Source/WebCore/rendering/RenderGrid.h:
Canonical link: https://commits.webkit.org/275376@main
Canonical link: https://commits.webkit.org/274313.188@webkitglib/2.44
Commit: 6aa74dcba79d2629e5d65691759c31842a4ce09a
https://github.com/WebKit/WebKit/commit/6aa74dcba79d2629e5d65691759c31842a4ce09a
Author: Vivienne Watermeier <vwaterme...@igalia.com>
Date: 2024-05-02 (Thu, 02 May 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/TrackPrivateBaseGStreamer.cpp
Log Message:
-----------
Cherry-pick 275378@main (877ae86c324a).
https://bugs.webkit.org/show_bug.cgi?id=270100
[GStreamer] Fix trimming of track IDs
https://bugs.webkit.org/show_bug.cgi?id=270100
Reviewed by Xabier Rodriguez-Calvar.
Use StringView::find() to trim zeroes instead of ::trim(), to not remove
trailing zeroes.
See previous PR: https://github.com/WebKit/WebKit/pull/23668
* Source/WebCore/platform/graphics/gstreamer/TrackPrivateBaseGStreamer.cpp:
(WebCore::trimStreamId): fix implementation
Canonical link: https://commits.webkit.org/275378@main
Canonical link: https://commits.webkit.org/274313.189@webkitglib/2.44
Commit: 962422e351686b79e5cfbd4e3adf20e292346189
https://github.com/WebKit/WebKit/commit/962422e351686b79e5cfbd4e3adf20e292346189
Author: Michael Saboff <msab...@apple.com>
Date: 2024-05-02 (Thu, 02 May 2024)
Changed paths:
M JSTests/stress/regexp-lookbehind.js
M Source/JavaScriptCore/yarr/YarrInterpreter.cpp
Log Message:
-----------
Cherry-pick 278204@main (a330a52f59a8).
https://bugs.webkit.org/show_bug.cgi?id=273426
[JSC] ASSERTION FAILED: pos >= negativePositionOffest in char32_t
JSC::Yarr::Interpreter<unsigned char>::InputStream::readChecked(unsigned int)
https://bugs.webkit.org/show_bug.cgi?id=273426
rdar://127013077
Reviewed by Keith Miller.
Added the same position version offest check to
backtrackPatternCasedCharacter() that existed in backtrackPatternCharacter().
Also fixed the restoration of the offest for a negative lookbehind
assertion.
Updated test.
* JSTests/stress/regexp-lookbehind.js:
* Source/JavaScriptCore/yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::backtrackPatternCasedCharacter):
(JSC::Yarr::Interpreter::backtrackParentheticalAssertionBegin):
Canonical link: https://commits.webkit.org/278204@main
Canonical link: https://commits.webkit.org/274313.190@webkitglib/2.44
Compare: https://github.com/WebKit/WebKit/compare/4746fa7ce6f9...962422e35168
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
