[webkit-changes] [WebKit/WebKit] 21a14e: Cherry-pick 274730 at main (f270bdb7b34c). https://bu...
Michael Saboff
noreply at github.com
Thu May 2 03:22:28 PDT 2024
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 <calvaris at 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 at 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 <pgorszkowski at 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 at 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 <calvaris at 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 at 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.lampe at 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 <charliew at apple.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebFrame.cpp
Log Message:
-----------
Cherry-pick 275113 at 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 at 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 <akeerthi at 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 at 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 at 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 at main.
272752 at 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 <rbuis at 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 at 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 <qianlangchen at 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 at 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+github at gmail.com>
Date: 2024-04-28 (Sun, 28 Apr 2024)
Changed paths:
M Source/WebInspectorUI/UserInterface/Models/CSSKeywordCompletions.js
Log Message:
-----------
Cherry-pick 275160 at 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 at 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 <philn at 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 at 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 <philn at 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 at 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 <rbuis at 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 at 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 <rniwa at 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 at 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 <philn at 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 at 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 <destra at 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 at 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 <cdumez at 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 at 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.suzuki at 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 at 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 <jya at 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 at 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_liu at 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 at 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_rosario at 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 at 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 <rbuis at 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 at main (dd25a04355e3). https://bugs.webkit.org/show_bug.cgi?id=268874
Regression (Safari 17 vs 16.5, 261003 at 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 <vwatermeier at 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 at 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 <msaboff at 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 at 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
More information about the webkit-changes
mailing list