Branch: refs/heads/webkitglib/2.50
Home: https://github.com/WebKit/WebKit
Commit: 6423977ce0e32bb70c760b7e5051e0f83ae999ef
https://github.com/WebKit/WebKit/commit/6423977ce0e32bb70c760b7e5051e0f83ae999ef
Author: Sihui Liu <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A
LayoutTests/http/wpt/webaudio/the-audio-api/the-audioworklet-interface/options-range-error-expected.txt
A
LayoutTests/http/wpt/webaudio/the-audio-api/the-audioworklet-interface/options-range-error.html
M Source/WebCore/Modules/webaudio/AudioWorkletNode.cpp
Log Message:
-----------
Cherry-pick 297297.215@safari-7622-branch (d4b50b1f7725). rdar://156322582
Avoid careating AudioWorkletNode with out-of-range parameters
rdar://156322582
Reviewed by Ryosuke Niwa.
Existing implementation allows clients to create AudioWorkletNode with
numberOfInputs and numberOfOutputs up to
UINT32_MAX, and this could lead to web content process crash when
AudioWorkletNode tries to constuct Vectors with big
size. To avoid that, now we set the maximum allowed numbers to be
UINT16_MAX (to match Firefox's behavior), and throw
RangeError if parameter is out of range.
*
LayoutTests/http/wpt/webaudio/the-audio-api/the-audioworklet-interface/options-range-error-expected.txt:
Added.
*
LayoutTests/http/wpt/webaudio/the-audio-api/the-audioworklet-interface/options-range-error.html:
Added.
* Source/WebCore/Modules/webaudio/AudioWorkletNode.cpp:
(WebCore::AudioWorkletNode::create):
Canonical link: https://commits.webkit.org/297297.215@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.239@webkitglib/2.50
Commit: 646c20a495a2b594d34755bcff4ce6fa079265e1
https://github.com/WebKit/WebKit/commit/646c20a495a2b594d34755bcff4ce6fa079265e1
Author: Yijia Huang <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/stress/loop-unrolling-with-a-switch-tail-terminal.js
M Source/JavaScriptCore/dfg/DFGLoopUnrollingPhase.cpp
Log Message:
-----------
Cherry-pick 297297.245@safari-7622-branch (dc6269bc685f).
https://bugs.webkit.org/show_bug.cgi?id=297153
[JSC] Skip loop unrolling when tail has non-branch terminal
https://bugs.webkit.org/show_bug.cgi?id=297153
rdar://157755838
Reviewed by Yusuke Suzuki.
The loop unrolling phase assumed tail blocks always have Branch terminals,
but could encounter Switch terminals. Add an early check in locateTail() to
skip loops with non-Branch terminals, as the current implementation only
supports Branch-based loop structures.
Canonical link: https://commits.webkit.org/297297.245@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.240@webkitglib/2.50
Commit: 0d8e0c66011f615eb7a1ce9b4166d465ddaf2fd9
https://github.com/WebKit/WebKit/commit/0d8e0c66011f615eb7a1ce9b4166d465ddaf2fd9
Author: Said Abou-Hallawa <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A
LayoutTests/http/tests/security/offscreen-canvas-remote-read-remote-image-expected.txt
A
LayoutTests/http/tests/security/offscreen-canvas-remote-read-remote-image.html
M LayoutTests/platform/wpe/TestExpectations
M Source/WebCore/html/OffscreenCanvas.cpp
M Source/WebCore/html/canvas/PlaceholderRenderingContext.cpp
M Source/WebCore/html/canvas/PlaceholderRenderingContext.h
Log Message:
-----------
Cherry-pick 297297.288@safari-7622-branch (bdeaba2e1881).
https://bugs.webkit.org/show_bug.cgi?id=297566
Offscreen canvas allows leaking cross-origin image
https://bugs.webkit.org/show_bug.cgi?id=297566
rdar://157055145
Reviewed by Kimmo Kinnunen.
If a cross-origin image is drawn to an ImageBitmap and it is transferred to
an
OffscreenCanvas, the context of the output canvas should be tainted.
*
LayoutTests/http/tests/security/offscreen-canvas-remote-read-remote-image-expected.txt:
Added.
*
LayoutTests/http/tests/security/offscreen-canvas-remote-read-remote-image.html:
Added.
* Source/WebCore/html/OffscreenCanvas.cpp:
(WebCore::OffscreenCanvas::commitToPlaceholderCanvas):
* Source/WebCore/html/canvas/PlaceholderRenderingContext.cpp:
(WebCore::PlaceholderRenderingContextSource::setPlaceholderBuffer):
(WebCore::PlaceholderRenderingContext::setPlaceholderBuffer):
* Source/WebCore/html/canvas/PlaceholderRenderingContext.h:
Canonical link: https://commits.webkit.org/297297.288@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.241@webkitglib/2.50
Commit: 5c7a44aa11cd5071b688f6168c29d10bc5198364
https://github.com/WebKit/WebKit/commit/5c7a44aa11cd5071b688f6168c29d10bc5198364
Author: Yusuke Suzuki <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/stress/map-set-iterator-speculated-types.js
M Source/JavaScriptCore/bytecode/SpeculatedType.cpp
M Source/JavaScriptCore/bytecode/SpeculatedType.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/dfg/DFGUseKind.h
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/runtime/JSType.h
Log Message:
-----------
Cherry-pick 297297.289@safari-7622-branch (528c899d1d87).
https://bugs.webkit.org/show_bug.cgi?id=297662
[JSC] JSMapIterator and JSSetIterator need to have distinct SpeculatedTypes
for Use edge filtering
https://bugs.webkit.org/show_bug.cgi?id=297662
rdar://158692260
Reviewed by Yijia Huang.
Each Use edge filtering needs distinct SpeculatedTypes. However
JSMapIterator and JSSetIterator were using SpecObjectOther bucket, which
can be used for different types. This fails to ensure that edge
filtering's type guarantee. This patch adds SpecMapIteratorObject and
SpecSetIteratorObject and uses them instead.
* JSTests/stress/map-set-iterator-speculated-types.js: Added.
(test):
* Source/JavaScriptCore/bytecode/SpeculatedType.cpp:
(JSC::speculationFromJSType):
* Source/JavaScriptCore/bytecode/SpeculatedType.h:
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
* Source/JavaScriptCore/dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* Source/JavaScriptCore/runtime/JSType.h:
Canonical link: https://commits.webkit.org/297297.289@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.242@webkitglib/2.50
Commit: 47e5ad0bafb54cc4d06ecd183d6469e24d16f45e
https://github.com/WebKit/WebKit/commit/47e5ad0bafb54cc4d06ecd183d6469e24d16f45e
Author: Keith Miller <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/stress/map-rehash-oom.js
A JSTests/stress/set-rehash-oom.js
M Source/JavaScriptCore/runtime/OrderedHashTableHelper.h
Log Message:
-----------
Cherry-pick 297297.293@safari-7622-branch (5b49a0d04fbe).
https://bugs.webkit.org/show_bug.cgi?id=297708
Clean up OrderedHashTable Resizing
https://bugs.webkit.org/show_bug.cgi?id=297708
rdar://158014775
Reviewed by Yusuke Suzuki.
When inserting into an OrderedHashTable, if the buffer is resized then
subsequently an
exception is thrown. The original buffer will be left in a inconsistent
state. This patch
takes two approaches to this problem:
1) Compute the hash key before resizing. This isn't observable semantically
since resizing
can only OOM and that is free to happen anywhere.
2) Only commit the new buffer once everything is set up. This way if we
change our design
in the future and throw somewhere in the middle we'll just roll back to the
previous state.
Lastly, convert some shifts into multiplications/divisions by the
appropriate power of two.
Clang will convert the muls/divs into the corresponding shifts so we should
focus on
readability.
Canonical link: https://commits.webkit.org/297297.293@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.243@webkitglib/2.50
Commit: 226a5abb2a36d76979814a7b2e673f3c030f88a5
https://github.com/WebKit/WebKit/commit/226a5abb2a36d76979814a7b2e673f3c030f88a5
Author: Phinehas Fuachie <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A LayoutTests/webaudio/AudioParam/exponential-ramp-crash-expected.txt
A LayoutTests/webaudio/AudioParam/exponential-ramp-crash.html
M Source/WebCore/Modules/webaudio/AudioParamTimeline.cpp
M Source/WebCore/Modules/webaudio/AudioParamTimeline.h
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebCore/ExponentialRampAtTimeTest.cpp
Log Message:
-----------
Cherry-pick 297297.313@safari-7622-branch (6d65d918b410).
https://bugs.webkit.org/show_bug.cgi?id=297579
Exponential ramp can produce NaN when starting value is zero
https://bugs.webkit.org/show_bug.cgi?id=297579
rdar://157301250
Reviewed by Darin Adler and Youenn Fablet.
Return the start value when value1 == 0 or value1 and value2 have opposite
signs, matching Blink
and the spec. This prevents invalid exponential ramps across zero. Added
test cases for
positive→negative, negative→positive, and zero start.
* LayoutTests/webaudio/AudioParam/exponential-ramp-crash-expected.txt:
Added.
* LayoutTests/webaudio/AudioParam/exponential-ramp-crash.html: Added.
* Source/WebCore/Modules/webaudio/AudioParamTimeline.cpp:
(WebCore::AudioParamTimeline::exponentialRampAtTime):
* Source/WebCore/Modules/webaudio/AudioParamTimeline.h:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebCore/ExponentialRampAtTimeTest.cpp: Added.
(expInterp):
(TEST(WebCore, AudioParamTimeline_OppositeSigns_PositiveToNegative)):
(TEST(WebCore, AudioParamTimeline_OppositeSigns_NegativeToPositive)):
(TEST(WebCore, AudioParamTimeline_OppositeSigns_MultipleTimes)):
(TEST(WebCore, AudioParamTimeline_OppositeSigns_SmallMagnitudes)):
(TEST(WebCore, AudioParamTimeline_OppositeSigns_LargeMagnitudes)):
(TEST(WebCore, AudioParamTimeline_SameSign_PositiveFollowsExponential)):
(TEST(WebCore, AudioParamTimeline_SameSign_NegativeFollowsExponential)):
Canonical link: https://commits.webkit.org/297297.313@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.244@webkitglib/2.50
Commit: 84c55112580c86ff9897ba2c084af734917e06ee
https://github.com/WebKit/WebKit/commit/84c55112580c86ff9897ba2c084af734917e06ee
Author: Kimmo Kinnunen <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/ThirdParty/ANGLE/src/compiler/translator/Compiler.cpp
M Source/ThirdParty/ANGLE/src/compiler/translator/ValidateOutputs.cpp
M Source/ThirdParty/ANGLE/src/tests/gl_tests/GLSLTest.cpp
Log Message:
-----------
Cherry-pick ANGLE. https://bugs.webkit.org/show_bug.cgi?id=297579
rdar://157514194
Reviewed by Dan Glastonbury.
Translator: Fix location validation for inout
Without this validation, a shader using an inout variable can
write into a memory beyond the limit set by MaxDrawBuffers when
shader framebuffer fetch is enabled.
* Extended the location check in visitSymbol() to include InOut
qualifiers (EvqFragmentInOut) as well (in ValidateOutputsTraverser).
* Moved RewritePixelLocalStorage() after ValidateOutputs() to avoid
issues related to locations not being specified in the InOut nodes
from the PLS implementation.
* Added a unit test to test that this case results in a compilation
error: GLSLTest_ES3.CompileFSWithInoutLocBeyondMaxDrawBuffers
Bug: chromium:435139154
Change-Id: I44c729377a2e1d3126c2d279172217b2ab92b57b
Reviewed-on:
https://chromium-review.googlesource.com/c/angle/angle/+/6806230
Reviewed-by: Shahbaz Youssefi <[email protected]>
Reviewed-by: Yuxin Hu <[email protected]>
Commit-Queue: Shahbaz Youssefi <[email protected]>
Canonical link: https://commits.webkit.org/297297.317@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.245@webkitglib/2.50
Commit: 5005cb7bbbc6405f4badc859337840bdf20ad430
https://github.com/WebKit/WebKit/commit/5005cb7bbbc6405f4badc859337840bdf20ad430
Author: Youenn Fablet <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A LayoutTests/http/tests/media/resources/hls/.htaccess
M LayoutTests/http/tests/media/resources/video-cookie-check-cookie.py
A
LayoutTests/http/tests/performance/performance-resource-timing-cross-origin-media-expected.txt
A
LayoutTests/http/tests/performance/performance-resource-timing-cross-origin-media-with-cors-expected.txt
A
LayoutTests/http/tests/performance/performance-resource-timing-cross-origin-media-with-cors.html
A
LayoutTests/http/tests/performance/performance-resource-timing-cross-origin-media.html
A
LayoutTests/http/tests/performance/performance-resource-timing-redirection-cross-origin-media-expected.txt
A
LayoutTests/http/tests/performance/performance-resource-timing-redirection-cross-origin-media-with-cors-expected.txt
A
LayoutTests/http/tests/performance/performance-resource-timing-redirection-cross-origin-media-with-cors.html
A
LayoutTests/http/tests/performance/performance-resource-timing-redirection-cross-origin-media.html
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Source/WebCore/loader/MediaResourceLoader.cpp
M Source/WebCore/loader/MediaResourceLoader.h
Log Message:
-----------
Cherry-pick 297297.327@safari-7622-branch (73b19a9b10d5).
https://bugs.webkit.org/show_bug.cgi?id=297579
HLS: Performance.getEntries() leaks contents of cross-site playlists
rdar://133406290
Reviewed by Eric Carlson.
When loading a manifest and the manifest is opaque, we cannot let the web
page know about loads triggered from that manifest.
We thus need to use LoadedFromOpaqueSource, like done for CSS. This will
prevent service worker interception and performance exposure.
We do not know whether a media load is triggered from a particular manifest
unfortunately.
We do the following heuristic as a workaround:
- As long as opaque source loading is not enabled, we check each opaque
response mime type.
- If an opaque response mime type is a manifest mime type, all remaining
loads of the current media will be LoadedFromOpaqueSource::Yes.
- If a load was previously done in non opaque mode, we continue doing so,
to not disrupt successive media range requests.
* LayoutTests/http/tests/media/resources/hls/.htaccess: Added.
* LayoutTests/http/tests/media/resources/video-cookie-check-cookie.py:
*
LayoutTests/http/tests/performance/performance-resource-timing-cross-origin-media-expected.txt:
Added.
*
LayoutTests/http/tests/performance/performance-resource-timing-cross-origin-media-with-cors-expected.txt:
Added.
*
LayoutTests/http/tests/performance/performance-resource-timing-cross-origin-media-with-cors.html:
Added.
*
LayoutTests/http/tests/performance/performance-resource-timing-cross-origin-media.html:
Added.
*
LayoutTests/http/tests/performance/performance-resource-timing-redirection-cross-origin-media-expected.txt:
Added.
*
LayoutTests/http/tests/performance/performance-resource-timing-redirection-cross-origin-media-with-cors-expected.txt:
Added.
*
LayoutTests/http/tests/performance/performance-resource-timing-redirection-cross-origin-media-with-cors.html:
Added.
*
LayoutTests/http/tests/performance/performance-resource-timing-redirection-cross-origin-media.html:
Added.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Source/WebCore/loader/MediaResourceLoader.cpp:
(WebCore::computeLoadedFromOpaqueSource):
(WebCore::MediaResourceLoader::requestResource):
(WebCore::isManifestMIMEType):
(WebCore::MediaResourceLoader::verifyMediaResponse):
(WebCore::MediaResourceLoader::redirectReceived):
(WebCore::MediaResource::redirectReceived):
* Source/WebCore/loader/MediaResourceLoader.h:
Canonical link: https://commits.webkit.org/297297.327@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.246@webkitglib/2.50
Commit: c6d829423fa0ac74221ff099cd5d077e7dd13aca
https://github.com/WebKit/WebKit/commit/c6d829423fa0ac74221ff099cd5d077e7dd13aca
Author: Darryl Parkinson <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkBroadcastChannelRegistry.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/NetworkProcess/Notifications/NetworkNotificationManager.cpp
M
Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorkerServerConnection.cpp
Log Message:
-----------
Cherry-pick 297297.328@safari-7622-branch (cb36c0c6b490).
https://bugs.webkit.org/show_bug.cgi?id=296444
fix potential lifetime issues retrieving sharedpreferences
https://bugs.webkit.org/show_bug.cgi?id=296444
rdar://problem/156628694
Reviewed by Sihui Liu.
Potential lifetime issue when accessing
webProcessConnection->sharedPreferencesForWebProcess() as webProcessConnection
could be null, fixed this by holding references correctly
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::protectedWebProcessConnection const):
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebKit/NetworkProcess/Notifications/NetworkNotificationManager.cpp:
(WebKit::NetworkNotificationManager::sharedPreferencesForWebProcess const):
*
Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorkerServerConnection.cpp:
(WebKit::WebSharedWorkerServerConnection::sharedPreferencesForWebProcess
const):
Canonical link: https://commits.webkit.org/297297.328@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.247@webkitglib/2.50
Commit: 1fe4cba93d189504074226b94d6668453e3a34b9
https://github.com/WebKit/WebKit/commit/1fe4cba93d189504074226b94d6668453e3a34b9
Author: Darryl Parkinson <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.messages.in
Log Message:
-----------
Cherry-pick 297297.333@safari-7622-branch (8d500b316ffc).
https://bugs.webkit.org/show_bug.cgi?id=298049
Remove FileSystemEnabled guard on endpoints
https://bugs.webkit.org/show_bug.cgi?id=298049
rdar://159340350
Reviewed by Sihui Liu.
Remove incorrect flags added to NetworkStorageManager messages.
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.messages.in:
Canonical link: https://commits.webkit.org/297297.333@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.248@webkitglib/2.50
Commit: 0c2dab9632199f417d1697c9e0369d87ae7f2203
https://github.com/WebKit/WebKit/commit/0c2dab9632199f417d1697c9e0369d87ae7f2203
Author: Rob Buis <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A
LayoutTests/fast/css/content-visibility-container-with-oof-child-crash-expected.txt
A
LayoutTests/fast/css/content-visibility-container-with-oof-child-crash.html
M Source/WebCore/rendering/RenderBlock.cpp
Log Message:
-----------
Cherry-pick [email protected] (2f7305a50eb3).
https://bugs.webkit.org/show_bug.cgi?id=295244
ASAN_SEGV | WebCore::Path::strokeContains;
WebCore::LegacyRenderSVGPath::shapeDependentStrokeContains;
WebCore::SVGGeometryElement::isPointInStroke
https://bugs.webkit.org/show_bug.cgi?id=295244
rdar://154646149
Reviewed by Alan Baradlay.
Prevent simplified layout on a c-v root with a previously skipped subtree,
since that means any out of flow
children in the subtree have not been processed yet, and only the normal
layout path handles them correctly.
*
LayoutTests/fast/css/content-visibility-container-with-oof-child-crash-expected.txt:
Added.
*
LayoutTests/fast/css/content-visibility-container-with-oof-child-crash.html:
Added.
* Source/WebCore/rendering/RenderBlock.cpp:
(WebCore::RenderBlock::canPerformSimplifiedLayout const):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.249@webkitglib/2.50
Commit: 66ffaaf7c97da7f5d384448e68e4d1ff975c0bd2
https://github.com/WebKit/WebKit/commit/66ffaaf7c97da7f5d384448e68e4d1ff975c0bd2
Author: Claudio Saavedra <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A LayoutTests/fast/css/immutable-properties-crash-expected.txt
A LayoutTests/fast/css/immutable-properties-crash.html
M Source/WTF/wtf/text/StringHash.h
M Source/WebCore/css/ImmutableStyleProperties.cpp
Log Message:
-----------
Cherry-pick [email protected] (c54787bc3732).
https://bugs.webkit.org/show_bug.cgi?id=295927
ASAN_ILL | WebCore::ImmutableStyleProperties::createDeduplicating;
WebCore::createStyleProperties; WebCore::CSSParser::parseInlineStyleDeclaration
https://bugs.webkit.org/show_bug.cgi?id=295927
rdar://155792201
Reviewed by Simon Fraser.
AlreadyHashed::avoidDeletedValue() always returns the passed hash, as
the or-bitwise operator doesn't really do anything. If the expected
behavior of this method is to avoid the special 0xFFFFFFFF value,
then I strongly suspect that what was intended was to use a xor-bitwise
operation; this will indeed flip the topmost bit if the hash is
0xFFFFFFFF but leave it unchanged for any other value (except 0,
of course).
ImmutableStyleProperties should use this method when adding elements
to its hash map, to make sure that it doesn't accidentally try to
insert a value whose hash key is 0xFFFFFFFF. Otherwise it will
hit an assertion.
* LayoutTests/fast/css/immutable-properties-crash-expected.txt: Added.
* LayoutTests/fast/css/immutable-properties-crash.html: Added.
* Source/WTF/wtf/text/StringHash.h:
(WTF::AlreadyHashed::avoidDeletedValue):
* Source/WebCore/css/ImmutableStyleProperties.cpp:
(WebCore::ImmutableStyleProperties::createDeduplicating):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.250@webkitglib/2.50
Commit: ef2c77d589fc722a568915c513ab9d52527b7551
https://github.com/WebKit/WebKit/commit/ef2c77d589fc722a568915c513ab9d52527b7551
Author: Rob Buis <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A LayoutTests/svg/animations/key-times-zero-path-crash-expected.html
A LayoutTests/svg/animations/key-times-zero-path-crash.html
M Source/WebCore/svg/SVGAnimationElement.cpp
Log Message:
-----------
Cherry-pick [email protected] (278e39816d42).
https://bugs.webkit.org/show_bug.cgi?id=295930
ASAN_ILL | WTF::Markable::operator*;
WebCore::LegacyRenderSVGRoot::repaintRectInLocalCoordinates;
WebCore::LegacyRenderSVGRoot::localClippedOverflowRect
https://bugs.webkit.org/show_bug.cgi?id=295930
rdar://155792445
Reviewed by Said Abou-Hallawa.
Ending the keyTimes list with 0 should be treated as an invalid animation
for animateMotion. While this
does not seem specified, it is what Chrome does.
* LayoutTests/svg/animations/key-times-zero-path-crash-expected.html: Added.
* LayoutTests/svg/animations/key-times-zero-path-crash.html:
* Source/WebCore/svg/SVGAnimationElement.cpp:
(WebCore::parseKeyTimes):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/297297.336@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.251@webkitglib/2.50
Commit: 2baada1a313172ffb06d126966cab8e965f9930f
https://github.com/WebKit/WebKit/commit/2baada1a313172ffb06d126966cab8e965f9930f
Author: Rob Buis <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A
LayoutTests/fast/css/content-visibility-with-multi-column-and-view-transition-crash-expected.txt
A
LayoutTests/fast/css/content-visibility-with-multi-column-and-view-transition-crash.html
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Cherry-pick [email protected] (fad8efb954b8).
https://bugs.webkit.org/show_bug.cgi?id=295932
Bug 295932 ASAN_SEGV | WebCore::RenderFragmentedFlow::boxIsFragmented;
WebCore::rendererIsFragmented; WebCore::forEachRendererInPaintOrder
https://bugs.webkit.org/show_bug.cgi?id=295932
rdar://155792317
Reviewed by Alan Baradlay.
View transition algorithms test whether a renderer is frsgmented or not,
however when content-visibility: hidden
causes a subtree to be hidden the fragmentation information is not always
fully computed. To fix this avoid
early returns due to content-visibility: hidden when fragmented flows are
involved.
*
LayoutTests/fast/css/content-visibility-with-multi-column-and-view-transition-crash-expected.txt:
Added.
*
LayoutTests/fast/css/content-visibility-with-multi-column-and-view-transition-crash.html:
Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::layoutInFlowChildren):
(WebCore::RenderBlockFlow::layoutBlockChildren):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.252@webkitglib/2.50
Commit: 5ff405d17dd1b93ca1f5ad71c37aa74d1c63deaf
https://github.com/WebKit/WebKit/commit/5ff405d17dd1b93ca1f5ad71c37aa74d1c63deaf
Author: Frédéric Wang <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A LayoutTests/fast/grid/nested-grid-and-subgrid-crash-expected.txt
A LayoutTests/fast/grid/nested-grid-and-subgrid-crash.html
M Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp
Log Message:
-----------
Cherry-pick [email protected] (22c1764572c2).
https://bugs.webkit.org/show_bug.cgi?id=295928
ASAN_TRAP | WebCore::GridTrackSizingAlgorithm::gridAreaBreadthForGridItem
https://bugs.webkit.org/show_bug.cgi?id=295928
rdar://155792516
Reviewed by Alan Baradlay.
After https://commits.webkit.org/296300@main, it's possible that
`GridTrackSizingAlgorithm::gridAreaBreadthForGridItem()` dereferences
`spannedRowsSize`, causing a release crash if the value returned by
`GridTrackSizingAlgorithm::estimatedGridAreaBreadthForGridItem()` is a
`nullopt`, as it is the case in the new test added by this patch.
Checking carefully, such a nullopt can only be returned for indefinite
grid area with an a grid item parallel to the `m_renderGrid`. In
https://commits.webkit.org/206127@main, a debug assert was added to
guarantee grid item is actually orthogonal, which is probably why the
code is written in a way that assumes the return value is not a nullopt.
However, this assert fails for the simple configuration below. Indeed,
`minContentContributionForGridItem` is called with m_renderGrid being
(the div of) id=grid and arguments (the div of) id=griditem. Because
of id=griditem's `writing-mode`, this in turn calls the method
`updateOverridingContainingBlockContentSizeForGridItem` with
parameters id=griditem and `GridTrackSizingDirection::Rows`. Because of
id=subgrid's `grid-template-columns`, the same method is called
recursively with arguments id=subgrid and
`GridTrackSizingDirection::Rows`. Finally, `gridAreaBreadthForGridItem`
is called with parallel m_renderGrid(id=grid) and gridItem(id=subgrid).
```
<div id="grid" style="display: grid">
<div id="subgrid" style="grid-template-columns: subgrid;">
<div id="griditem" style="writing-mode: vertical-lr"></div>
</div>
</div>
ASSERTION FAILED: GridLayoutFunctions::isOrthogonalGridItem(*m_renderGrid,
gridItem)
WebCore::GridTrackSizingAlgorithm::gridAreaBreadthForGridItem(WebCore::RenderBox
const&, WebCore::Style::GridTrackSizingDirection) const
WebCore::GridTrackSizingAlgorithmStrategy::updateOverridingContainingBlockContentSizeForGridItem(WebCore::RenderBox&,
WebCore::Style::GridTrackSizingDirection, std::optional<WebCore::LayoutUnit>)
const
WebCore::GridTrackSizingAlgorithmStrategy::updateOverridingContainingBlockContentSizeForGridItem(WebCore::RenderBox&,
WebCore::Style::GridTrackSizingDirection, std::optional<WebCore::LayoutUnit>)
const
WebCore::GridTrackSizingAlgorithmStrategy::minContentContributionForGridItem(WebCore::RenderBox&,
WebCore::GridLayoutState&) const
```
It's very likely that some wrong assumptions were made when subgrid
were introduced, `updateOverridingContainingBlockContentSizeForGridItem`
should probably now perform something more clever in order to handle the
case when `gridItem` can change its direction in the recursive call. But
in order to minimize behavior changes, this patch just makes
gridAreaBreadthForGridItem return a nullopt in the case where current
code tries to derefence a nullopt rowSpanForGridItem. The obsolete debug
ASSERT is removed.
* LayoutTests/fast/grid/nested-grid-and-subgrid-crash-expected.txt: Added.
* LayoutTests/fast/grid/nested-grid-and-subgrid-crash.html: Added.
* Source/WebCore/rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::gridAreaBreadthForGridItem const):
Remove obsolete ASSERT and return nullopt if spannedRowsSize is nullopt.
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/297297.338@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.253@webkitglib/2.50
Commit: 4b34a9f245113691c4ac5331f7e8042c0c892cde
https://github.com/WebKit/WebKit/commit/4b34a9f245113691c4ac5331f7e8042c0c892cde
Author: Daniel Liu <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/JavaScriptCore/b3/B3WasmBoundsCheckValue.cpp
M Source/JavaScriptCore/b3/B3WasmBoundsCheckValue.h
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
Log Message:
-----------
Cherry-pick 297297.360@safari-7622-branch (f5ded472170d).
https://bugs.webkit.org/show_bug.cgi?id=298129
OMG Wasm memory access should emit a full 64-bit immediate
https://bugs.webkit.org/show_bug.cgi?id=298129
rdar://159439036
Reviewed by Yusuke Suzuki.
Previously, OMG computed memory indices using a 32-bit integer, which could
overflow
at higher offsets. We switch this over to a 64-bit integer, allowing us to
avoid any
overflow conditions.
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp:
(JSC::Wasm::OMGIRGenerator::emitCheckAndPreparePointer):
Canonical link: https://commits.webkit.org/297297.360@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.254@webkitglib/2.50
Commit: 06075a516c0ea9ee1b3eb0afc37385f2ea3f8129
https://github.com/WebKit/WebKit/commit/06075a516c0ea9ee1b3eb0afc37385f2ea3f8129
Author: Daniel Liu <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp
Log Message:
-----------
Cherry-pick 297297.362@safari-7622-branch (cb6fcc0b908c).
https://bugs.webkit.org/show_bug.cgi?id=298126
DFG Constant Folding should ignore results of blocks which CFA has marked
unreachable
https://bugs.webkit.org/show_bug.cgi?id=298126
rdar://158662405
Reviewed by Yusuke Suzuki.
DFG's constant folding pass included value result information from blocks
which were found to be unreachable
through control flow analysis. This could lead to weaker type guarantees
during further analysis.
* Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
Canonical link: https://commits.webkit.org/297297.362@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.255@webkitglib/2.50
Commit: 54f90600a44ee83f5727438348d9da5bc5d6f1e8
https://github.com/WebKit/WebKit/commit/54f90600a44ee83f5727438348d9da5bc5d6f1e8
Author: Kimmo Kinnunen <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/ThirdParty/ANGLE/src/compiler/translator/Compiler.cpp
M
Source/ThirdParty/ANGLE/src/tests/compiler_tests/SeparateDeclarations_test.cpp
M Source/ThirdParty/ANGLE/src/tests/gl_tests/UniformTest.cpp
Log Message:
-----------
Cherry-pick ANGLE. https://bugs.webkit.org/show_bug.cgi?id=298126
rdar://159643967
Reviewed by Mike Wyrzykowski.
Cherry-pick ANGLE upstream 7cbb77a881028d07958395c1b7c7b36e169b59ed
rdar://159643967
Fix the uniform reorder bug
When sorting uniforms, we should first check if both uniforms are
structs, and make sure to place the uniforms with specifier in front
of the uniforms without specifier.
Bug: chromium:431318231
Change-Id: I8be9501f34073983b7f3d040780b749a7366e3d2
Reviewed-on:
https://chromium-review.googlesource.com/c/angle/angle/+/6733547
Reviewed-by: Amirali Abdolrashidi <[email protected]>
Commit-Queue: Yuxin Hu <[email protected]>
Cherry-pick ANGLE upstream 1d8279a2b7b6ce99ec7697d97db4eee3268bc52a
rdar://159643967
Fix sort uniform bug
Current sort doesn't take care of the case when both uniforms
are struct specfiers. Given that struct types are easily broken by
sort, make the sort not reordering uniforms if both are structs.
Bug: b/437825940
Change-Id: Idda1810ac4234f7e1547735e4e09658ab0a57eed
Reviewed-on:
https://chromium-review.googlesource.com/c/angle/angle/+/6842936
Reviewed-by: Charlie Lao <[email protected]>
Reviewed-by: Amirali Abdolrashidi <[email protected]>
Reviewed-by: Shahbaz Youssefi <[email protected]>
Cherry-pick ANGLE upstream 1d8279a2b7b6ce99ec7697d97db4eee3268bc52a
rdar://159643967
Do not sort ANGLE internal uniforms or built-in uniforms
On Mac, for webGL app on chrome, if the uniforms added by ANGLE
are not placed at the top of the ANGLE_UserUniforms struct, the user
defined uniforms in the same ANGLE_UserUniforms struct seem to be
messed up and not read correctly by shader code. This change fixes
it by moving the sortUniforms() function call to the place before we
add ANGLE internal uniforms. That way ANGLE internal uniforms will
be inserted later and stay on top of ANGLE_UserUniforms struct.
Bug: chromium:437678149
Change-Id: I34a0d3dcb98c5fe30ad248381ecb5f7f78252275
Reviewed-on:
https://chromium-review.googlesource.com/c/angle/angle/+/6847281
Auto-Submit: Yuxin Hu <[email protected]>
Commit-Queue: Yuxin Hu <[email protected]>
Reviewed-by: Shahbaz Youssefi <[email protected]>
Reviewed-by: Amirali Abdolrashidi <[email protected]>
Cherry-pick ANGLE upstream f63751db4c7fa10292eba38eda748e216b075d16
rdar://159643967
Fix the UniformSortComparator not following strict weak order
If one uniform is lowp and the other uniform is mediump, then the
compare(a, b) and compare (b, a) both return true. This violates the
strict weak order rule where:
If comp(a, b) == true then comp(b, a) == false
This change fixes the bug.
Bug: angleproject:405795981
Change-Id: I47e2668fc0fa87ecea9d3f9bce511c9823a39929
Reviewed-on:
https://chromium-review.googlesource.com/c/angle/angle/+/6876519
Reviewed-by: Amirali Abdolrashidi <[email protected]>
Commit-Queue: Yuxin Hu <[email protected]>
Canonical link: https://commits.webkit.org/297297.367@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.256@webkitglib/2.50
Commit: b4d0dda8dc41a7b506356b2505188b323ccac91d
https://github.com/WebKit/WebKit/commit/b4d0dda8dc41a7b506356b2505188b323ccac91d
Author: Antoine Quint <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A LayoutTests/webanimations/null-timeline-crash-expected.txt
A LayoutTests/webanimations/null-timeline-crash.html
M Source/WebCore/animation/ElementAnimationRareData.cpp
M Source/WebCore/animation/KeyframeEffect.cpp
M Source/WebCore/animation/KeyframeEffect.h
Log Message:
-----------
Cherry-pick 297297.371@safari-7622-branch (02618abc17c4).
https://bugs.webkit.org/show_bug.cgi?id=298317
ASAN_ILL | WebCore::KeyframeEffectStack::allowsAcceleration;
WebCore::KeyframeEffectStack::removeEffect;
WebCore::KeyframeEffect::updateEffectStackMembership
https://bugs.webkit.org/show_bug.cgi?id=298317
rdar://157023038
Reviewed by Cameron McCormack.
When a document is torn down, we call into
`AnimationTimelinesController::detachFromDocument()` which
will call `AnimationTimeline::detachFromDocument()` for each known timeline
and then `WebAnimation::remove()`
for each animation associated with that timeline. This will eventually
disassociate animation effects
from the `KeyframeEffectStack` of their target, ensuring there are no null
references in the stack's
list of effects.
However, with the advent of scroll-driven animations, an animation's
timeline may be set to null, which
will not perform such a disassociation since that animation may remain
"relevant" [0]. However, since
the cleanup described above occurs for animations associated with a
timeline, such timeline-less
animations will not be processed and thus it's possible that an effect is
destroyed but a (weak)
reference remains in the effect stack.
To address this issue, we add logic in the `KeyframeEffect` destructor to
remove itself from any associated
effect stack, and add an assertion that it is indeed no longer in that
stack. Additionally, we now check
in the `ElementAnimationRareData` destructor that it no longer has an
effect stack or that the stack is empty.
[0] https://drafts.csswg.org/web-animations-1/#relevant-animations-section
* LayoutTests/webanimations/null-timeline-crash-expected.txt: Added.
* LayoutTests/webanimations/null-timeline-crash.html: Added.
* Source/WebCore/animation/ElementAnimationRareData.cpp:
(WebCore::ElementAnimationRareData::~ElementAnimationRareData):
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::~KeyframeEffect):
* Source/WebCore/animation/KeyframeEffect.h:
Canonical link: https://commits.webkit.org/297297.371@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.257@webkitglib/2.50
Commit: da7d0e5ebab38e68c2bdc105eb8f450b1e291dad
https://github.com/WebKit/WebKit/commit/da7d0e5ebab38e68c2bdc105eb8f450b1e291dad
Author: Antti Koivisto <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A
LayoutTests/fast/css/custom-properties/registered-custom-property-revert-layer-crash-expected.txt
A
LayoutTests/fast/css/custom-properties/registered-custom-property-revert-layer-crash.html
M Source/WebCore/style/StyleBuilder.cpp
Log Message:
-----------
Cherry-pick 297297.373@safari-7622-branch (3800cebd8f22).
https://bugs.webkit.org/show_bug.cgi?id=298314
Registered properties and revert-layer may dereference disengaged
std::optional
https://bugs.webkit.org/show_bug.cgi?id=298314
rdar://157023648
Reviewed by Alan Baradlay.
*
LayoutTests/fast/css/custom-properties/registered-custom-property-revert-layer-crash-expected.txt:
Added.
*
LayoutTests/fast/css/custom-properties/registered-custom-property-revert-layer-crash.html:
Added.
* Source/WebCore/style/StyleBuilder.cpp:
(WebCore::Style::Builder::applyRollbackCascadeCustomProperty):
With registered properties custom property resolution may fail. Return
guaranteed-invalid value in this case.
Canonical link: https://commits.webkit.org/297297.373@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.258@webkitglib/2.50
Commit: fe9f36df4d3dfe88ea242c53bf65c2cf5f2558d0
https://github.com/WebKit/WebKit/commit/fe9f36df4d3dfe88ea242c53bf65c2cf5f2558d0
Author: Ronan Turner <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A
LayoutTests/fast/speechsynthesis/lockdown-mode/speech-synthesis-expected.txt
A LayoutTests/fast/speechsynthesis/lockdown-mode/speech-synthesis.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M LayoutTests/platform/win/TestExpectations
M LayoutTests/platform/wpe/TestExpectations
M Source/WebCore/Modules/speech/DOMWindow+SpeechSynthesis.idl
M Source/WebCore/bindings/js/WebCoreBuiltinNames.h
Log Message:
-----------
Cherry-pick 297297.375@safari-7622-branch (7d5ef34062b7).
https://bugs.webkit.org/show_bug.cgi?id=298382
Prevent speechSynthesis from being accessible in LDM.
https://bugs.webkit.org/show_bug.cgi?id=298382
rdar://159462101
Reviewed by Alex Christensen.
We were missing an EnabledBySetting=SpeechSynthesisAPIEnabled guard on the
DOMWindow+SpeechSynthesis.idl file. This results in window.speechSynthesis
still remaining accessible to sites, even when the setting is disabled. This
then results in process termination when the IPC message is attempted and
the
privileged process marks the IPC message as invalid.
This adds the guard, and a new test to ensure this is sufficiently disabled
when in Lockdown Mode.
*
LayoutTests/fast/speechsynthesis/lockdown-mode/speech-synthesis-expected.txt:
Added.
* LayoutTests/fast/speechsynthesis/lockdown-mode/speech-synthesis.html:
Added.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/mac-wk1/TestExpectations:
* LayoutTests/platform/win/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebCore/Modules/speech/DOMWindow+SpeechSynthesis.idl:
* Source/WebCore/bindings/js/WebCoreBuiltinNames.h:
Canonical link: https://commits.webkit.org/297297.375@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.259@webkitglib/2.50
Commit: 23f1b25666b36a76737abb644ec0a71b0141f13e
https://github.com/WebKit/WebKit/commit/23f1b25666b36a76737abb644ec0a71b0141f13e
Author: Yijia Huang <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/stress/array-allocation-sink-escape-materialize-15.js
M Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp
Log Message:
-----------
Cherry-pick 297297.382@safari-7622-branch (a1cadb6e8070).
https://bugs.webkit.org/show_bug.cgi?id=298356
[JSC] Ensure Sink+Escape+Materialize ArrayButterfly allocations are not
Escaped kind
rdar://159801389
https://bugs.webkit.org/show_bug.cgi?id=298356
Reviewed by Keith Miller.
When we Sink+Escape+Materialize an array, we also need to do
the same for its corresponding GetButterfly (ArrayButterfly allocation).
This is because GetButterfly cannot refer to a phantom array node - it
requires a materialized array. Therefore, when we Sink+Escape+Materialize
an ArrayButterfly allocation, we must ensure its allocation kind is
ArrayButterfly, not Escaped, so that createMaterialization() can properly
handle it.
Canonical link: https://commits.webkit.org/297297.382@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.260@webkitglib/2.50
Commit: 3f1e9093da43621c56c7d5a8db60653a86804e99
https://github.com/WebKit/WebKit/commit/3f1e9093da43621c56c7d5a8db60653a86804e99
Author: Sihui Liu <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/WebCore/Modules/indexeddb/server/MemoryBackingStoreTransaction.cpp
M Source/WebCore/Modules/indexeddb/server/MemoryBackingStoreTransaction.h
Log Message:
-----------
Cherry-pick 297297.386@safari-7622-branch (70a1e97f4ce6).
https://bugs.webkit.org/show_bug.cgi?id=298356
Fix use-after-free in MemoryBackingStoreTransaction::abort
rdar://159649671
Reviewed by Per Arne Vollan and Rupin Mittal.
MemoryIndex can be destroyed after the last reference is removed in
MemoryBackingStoreTransaction::removeNewIndex(), but
MemoryBackingStoreTransaction::m_originalIndexNames might still keep the
raw pointer to the MemoryIndex, and when
transaction is aborted later, MemoryBackingStoreTransaction::abort would
access the pointer. To fix this, ensure
the MemoryIndex is removed from m_originalIndexNames in removeNewIndex().
Also, to avoid this use-after-free issue,
make m_originalIndexNames store RefPtr instead of raw pointer.
* Source/WebCore/Modules/indexeddb/server/MemoryBackingStoreTransaction.cpp:
(WebCore::IDBServer::MemoryBackingStoreTransaction::removeNewIndex):
(WebCore::IDBServer::MemoryBackingStoreTransaction::abort):
* Source/WebCore/Modules/indexeddb/server/MemoryBackingStoreTransaction.h:
Canonical link: https://commits.webkit.org/297297.386@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.261@webkitglib/2.50
Commit: f661a52c83d4fa3348ba05632c62fd5e21f7ff7b
https://github.com/WebKit/WebKit/commit/f661a52c83d4fa3348ba05632c62fd5e21f7ff7b
Author: Sihui Liu <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/WebKit/Platform/IPC/Connection.cpp
Log Message:
-----------
Cherry-pick 297297.390@safari-7622-branch (cef844c4512c).
https://bugs.webkit.org/show_bug.cgi?id=298489
Stop using raw pointer in syncMessageStateMap()
https://bugs.webkit.org/show_bug.cgi?id=298489
rdar://156584462
Reviewed by Chris Dumez.
Connection::SyncMessageStateRelease::operator() only removes entry from
syncMessageStateMap() if instance's dispatcher
is not null (i.e. dispatcher has not been destroyed). This means if
dispatcher is destroyed, the map would keep a
dangling pointer that is not to be removed.
* Source/WebKit/Platform/IPC/Connection.cpp:
Canonical link: https://commits.webkit.org/297297.390@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.262@webkitglib/2.50
Commit: 77750fd03a278aae44055021a610c0d6cc6c4c06
https://github.com/WebKit/WebKit/commit/77750fd03a278aae44055021a610c0d6cc6c4c06
Author: Vassili Bykov <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmGlobal.h
M Source/JavaScriptCore/wasm/WasmTable.cpp
M Source/JavaScriptCore/wasm/WasmTable.h
M Source/JavaScriptCore/wasm/WasmTypeDefinition.h
M Source/JavaScriptCore/wasm/WasmTypeDefinitionInlines.h
Log Message:
-----------
Cherry-pick 297297.393@safari-7622-branch (b3e1519a9399).
https://bugs.webkit.org/show_bug.cgi?id=297958
Retain the TypeDefinition underlying the Wasm::Type in Wasm::Global and
Wasm::Table
https://bugs.webkit.org/show_bug.cgi?id=297958
rdar://159278266
Reviewed by Yusuke Suzuki.
Wasm::Global and Wasm::Table both have a field containing a Wasm::Type
describing the
value of the global or the contents of the table. Wasm::Type has a field
`index` of type
`TypeIndex`. Formally, `TypeIndex` is an alias for `uintptr_t`. However,
the field may
actually be a pointer to the `TypeDefinition` instance corresponding to the
type.
Because TypeDefinitions are refcounted but Wasm::Type contains a raw
unmanaged pointer, it
is possible for a pointer in Wasm::Type to outlive the TypeDefinition it
points to. This
can happen with Wasm Globals and Tables because an exported global or a
table (if it's
empty) may outlive their associated Wasm instance when they are retained by
JavaScript
code. In that situation TypeDefinitions referenced by the instance may be
garbage-collected while pointers to them from the globals or tables still
exist. After
that, an attempt to set the value of the global or a table entry will
dereference the
dangling pointer as the value is validated against the type of the global
or the table.
This patch adds an explicit counted TypeDefinition reference to Wasm::Global
and Wasm::Table to ensure the TypeDefinition lives long enough.
Ideally, we might want to redesign Wasm::Type to have it carry a proper
counted reference
to its TypeDefinition instead of a disguised raw pointer. But that is a
larger
undertaking, while in the meantime this patch fixes the known vulnerability.
Canonical link: https://commits.webkit.org/297297.393@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.263@webkitglib/2.50
Commit: cc19452abc3ba4926113a904d0d6f9435d25896a
https://github.com/WebKit/WebKit/commit/cc19452abc3ba4926113a904d0d6f9435d25896a
Author: Gavin Phillips <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/WebKit/GPUProcess/graphics/RemoteImageBuffer.cpp
Log Message:
-----------
Cherry-pick 297297.395@safari-7622-branch (03d5765621f7).
https://bugs.webkit.org/show_bug.cgi?id=298092
Verify resolutionScale() in GPU Process Before Calling putPixelBuffer
https://bugs.webkit.org/show_bug.cgi?id=298092
rdar://problem/78164875
Reviewed by Said Abou-Hallawa.
Verify resoultionScale is equal to 1 before calling putPixelBuffer.
Currently, this is validated on the client (WebContent) side but
not in the GPUP.
* Source/WebKit/GPUProcess/graphics/RemoteImageBuffer.cpp:
(WebKit::RemoteImageBuffer::putPixelBuffer):
Canonical link: https://commits.webkit.org/297297.395@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.264@webkitglib/2.50
Commit: 2fe1461d6a3c492e6b45a90ab0dc4735825a50a0
https://github.com/WebKit/WebKit/commit/2fe1461d6a3c492e6b45a90ab0dc4735825a50a0
Author: Daniel Liu <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/wasm/stress/ipint-bbq-osr-check-try-implicit-slot-overlap.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
M Source/JavaScriptCore/wasm/WasmOperations.cpp
Log Message:
-----------
Cherry-pick 297297.400@safari-7622-branch (d3b258b586e6).
https://bugs.webkit.org/show_bug.cgi?id=298196
BBQ stackmap should not write to try implicit slots
https://bugs.webkit.org/show_bug.cgi?id=298196
rdar://159610745
Reviewed by Yusuke Suzuki.
BBQ places the try block's implicit slot in the same Temp as the arguments.
This
can lead to Debug assertions firing since it doesn't expect a real value at
that
location. We should just not write to that slot when we parse the exception
slot
reserved by IPInt's OSR.
* JSTests/wasm/stress/ipint-bbq-osr-check-try-implicit-slot-overlap.js:
Added.
(instantiate):
(async let):
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::ControlData::implicitSlots const):
(JSC::Wasm::BBQJITImpl::BBQJIT::makeStackMap):
* Source/JavaScriptCore/wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_NOEXCEPT_JIT_OPERATION):
Canonical link: https://commits.webkit.org/297297.400@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.265@webkitglib/2.50
Commit: d7a650c33ec953c92cae3052f88db6bc1e783145
https://github.com/WebKit/WebKit/commit/d7a650c33ec953c92cae3052f88db6bc1e783145
Author: Yusuke Suzuki <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/stress/switch-imm-int32-max.js
M Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h
M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
M Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm
M Source/JavaScriptCore/llint/LowLevelInterpreter64.asm
M Source/JavaScriptCore/runtime/CachedTypes.cpp
Log Message:
-----------
Cherry-pick 297297.406@safari-7622-branch (9585bfc103fc).
https://bugs.webkit.org/show_bug.cgi?id=298628
[JSC] Have m_isList flag separately in UnlinkedSimpleJumpTable
https://bugs.webkit.org/show_bug.cgi?id=298628
rdar://159953039
Reviewed by Yijia Huang.
UnlinkedSimpleJumpTable should have a separate flag for m_isList not to
confuse with a switch which only has INT32_MAX entry for `case` clause.
* JSTests/stress/switch-imm-int32-max.js: Added.
(try.switch):
(catch):
* Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedSimpleJumpTable::isList const):
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::endSwitch):
* Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm:
* Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:
* Source/JavaScriptCore/runtime/CachedTypes.cpp:
(JSC::CachedSimpleJumpTable::encode):
(JSC::CachedSimpleJumpTable::decode const):
Canonical link: https://commits.webkit.org/297297.406@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.266@webkitglib/2.50
Commit: 524e07ff57389a4ffe05bb8bc734f174f9cd7527
https://github.com/WebKit/WebKit/commit/524e07ff57389a4ffe05bb8bc734f174f9cd7527
Author: Shu-yu Guo <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/wasm/stress/omg-tail-call-clobber-scratch-register.js
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp
Log Message:
-----------
Cherry-pick 297297.410@safari-7622-branch (cf7eb4a4e9c4).
https://bugs.webkit.org/show_bug.cgi?id=298496
[JSC] Fix spilling macro scratch reg in OMG tail calls
https://bugs.webkit.org/show_bug.cgi?id=298496
rdar://158613168
Reviewed by Mark Lam.
OMG does manual saving of the MacroAssembler scratch register when preparing
the frame for tail calls, because it uses it as a temp and it may interfere
with an input GPR. This logic is currently wrong in several ways:
- In assert-enabled builds, the register is spilled after it is already
clobbered.
- In assert-enabled builds, the stack spill location is overwritten before
it
is restored.
- The spill offset is relative to the original SP, and it is restored
relative
to the new SP after the frame is set up for the tail call.
This PR fixes these and adds the following modest safeguards:
- For tail call patchpoints that have an AnyRegister input, disallow
MacroAssembler scratch register usage by default so that after
prepareCall,
it is not accidentally clobbered in case it is an input GPR.
- Explicitly disallow scratch usage before saving and after restoring the
scratch register in prepareTailCallImpl. Stack clobbering is rewritten
to accommodate.
Canonical link: https://commits.webkit.org/297297.410@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.267@webkitglib/2.50
Commit: 930255ea665080de71998bec77897a06f70e40f1
https://github.com/WebKit/WebKit/commit/930255ea665080de71998bec77897a06f70e40f1
Author: Antoine Quint <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A
LayoutTests/webanimations/pause-after-switching-to-finite-timeline-expected.txt
A LayoutTests/webanimations/pause-after-switching-to-finite-timeline.html
M Source/WebCore/animation/WebAnimation.cpp
Log Message:
-----------
Cherry-pick 297297.417@safari-7622-branch (9a1fcd2847a2).
https://bugs.webkit.org/show_bug.cgi?id=298869
[WebKit][Main+SU] [bcdfa3892054a35c] ASAN_TRAP |
WebCore::WebAnimationTime::approximatelyLessThan;
WebCore::AnimationEffectTiming::getBasicTiming;
WebCore::AnimationEffect::getBasicTiming
https://bugs.webkit.org/show_bug.cgi?id=298869
rdar://160116687
Reviewed by Anne van Kesteren.
As part of 294049@main we started storing a "pending start time" for each
animation which we would
set to be the start time when marking the animation as ready. When
switching from a monotonic to a
progress-based timeline, we may be in a situation where that "pending start
time" was recorded based
on the monotonic timeline, and if the animation is paused with a monotonic
"pending start time" then
we will try to run some logic based on both monotonic and progress-based
times in `WebAnimation::runPendingPauseTask()`.
To address this, we reset the "pending start time" when switching
timelines, which makes sense regardless
of the type of timeline we're dealing with.
*
LayoutTests/webanimations/pause-after-switching-to-finite-timeline-expected.txt:
Added.
* LayoutTests/webanimations/pause-after-switching-to-finite-timeline.html:
Added.
* Source/WebCore/animation/WebAnimation.cpp:
(WebCore::WebAnimation::setTimelineInternal):
Canonical link: https://commits.webkit.org/297297.417@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.268@webkitglib/2.50
Commit: 695fe6142c13827782bb875fbaabc52c6dcd504d
https://github.com/WebKit/WebKit/commit/695fe6142c13827782bb875fbaabc52c6dcd504d
Author: Daniel Liu <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/JavaScriptCore/runtime/StringPrototype.cpp
M Source/WTF/wtf/unicode/icu/ICUHelpers.h
Log Message:
-----------
Cherry-pick 297297.419@safari-7622-branch (03c4ee731559).
https://bugs.webkit.org/show_bug.cgi?id=298232
Limit JSString length during Unicode operations to 1G characters
https://bugs.webkit.org/show_bug.cgi?id=298232
rdar://159665462
Reviewed by Yusuke Suzuki.
Unicode has some limits on string length, which can cause issues
when large strings are passed in. We should limit the max length
of strings to avoid hitting these limits, and raise an OOM if we
exceed this limit.
* Source/JavaScriptCore/runtime/StringPrototype.cpp:
(JSC::normalize):
Canonical link: https://commits.webkit.org/297297.419@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.269@webkitglib/2.50
Commit: 90d2c088b6063ae8fe4a00e9a338b95ae8abc2b3
https://github.com/WebKit/WebKit/commit/90d2c088b6063ae8fe4a00e9a338b95ae8abc2b3
Author: Yijia Huang <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/stress/loop-unrolling-multi-get-and-put-by-offset.js
M Source/JavaScriptCore/dfg/DFGCloneHelper.cpp
M Source/JavaScriptCore/dfg/DFGCloneHelper.h
Log Message:
-----------
Cherry-pick 297297.428@safari-7622-branch (0369cf4f5755).
https://bugs.webkit.org/show_bug.cgi?id=298851
[JSC] Fix DFG node cloning to properly copy mutable data structures
rdar://160593174
https://bugs.webkit.org/show_bug.cgi?id=298851
Reviewed by Yusuke Suzuki.
The DFG clone helper was incorrectly sharing mutable data structures between
original and cloned nodes during loop unrolling optimizations. This caused
inconsistent state when subsequent optimization phases modified the shared
data.
This patch ensures that nodes with mutable data structures are properly
cloned with
independent copies of their associated data.
Canonical link: https://commits.webkit.org/297297.428@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.270@webkitglib/2.50
Commit: 9fdc2596a3d48993db7df5c1fa06c7f0f3d96b6b
https://github.com/WebKit/WebKit/commit/9fdc2596a3d48993db7df5c1fa06c7f0f3d96b6b
Author: David Kilzer <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/WebCore/platform/sql/SQLiteDatabase.cpp
Log Message:
-----------
Cherry-pick 297297.445@safari-7622-branch (9acf4b8eff51).
https://bugs.webkit.org/show_bug.cgi?id=299218
Network process crash due to environment variable race in
libsystem_coreservices.dylib: _dirhelper_update_tmpdir
<https://bugs.webkit.org/show_bug.cgi?id=299218>
<rdar://160718740>
Reviewed by Per Arne Vollan and Darin Adler.
* Source/WebCore/platform/sql/SQLiteDatabase.cpp:
(WebCore::initializeSQLiteIfNecessary):
- Ensure that sqlite3_initialize() is called from the main thread to
avoid race conditions.
Canonical link: https://commits.webkit.org/297297.445@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.271@webkitglib/2.50
Commit: 1d5b8111776e1e2dcda92425a1dd288a84ed5fe4
https://github.com/WebKit/WebKit/commit/1d5b8111776e1e2dcda92425a1dd288a84ed5fe4
Author: Youenn Fablet <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/encode_api_test.cc
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_bitstream.c
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encodeframe.c
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_pickmode.c
Log Message:
-----------
Cherry-pick 297297.446@safari-7622-branch (010e247adf52).
https://bugs.webkit.org/show_bug.cgi?id=299218
Potential 'overflow' issue commited to upstream libwebrtc
rdar://159773684
Reviewed by Jean-Yves Avenard.
Cherry-picking of
https://github.com/webmproject/libvpx/commit/ba9dad15b83f791773452bc4889102cbdda50605
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/encode_api_test.cc:
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_bitstream.c:
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encodeframe.c:
(choose_partitioning):
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_pickmode.c:
(vp9_pick_intra_mode):
Canonical link: https://commits.webkit.org/297297.446@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.272@webkitglib/2.50
Commit: 0653b8fb9d569aa7b451f449cfacc3470c31b66a
https://github.com/WebKit/WebKit/commit/0653b8fb9d569aa7b451f449cfacc3470c31b66a
Author: Yusuke Suzuki <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/stress/dfg-proto-fold-invalidate.js
A JSTests/stress/dfg-proto-fold-invalidate2.js
M Source/JavaScriptCore/bytecode/GetByStatus.cpp
Log Message:
-----------
Cherry-pick 297297.455@safari-7622-branch (fb078f3ea09e).
https://bugs.webkit.org/show_bug.cgi?id=299307
[JSC] DFG compiler-side concurrent prototype access folding needs to
validate ObjectConditionSet
https://bugs.webkit.org/show_bug.cgi?id=299307
rdar://154481123
Reviewed by Yijia Huang.
DFG does concurrent prototype access folding. Before calling
generateConditionsForPrototypePropertyHitConcurrently,
DFG does its own lookup to avoid installing watchpoints for
non-beneficial cases (generateConditionsForPrototypePropertyHitConcurrently
is just creating ObjectConditionSet,
so in the most of cases, it succeeds regardless). But this lookup and
generateConditionsForPrototypePropertyHitConcurrently
are different, so we should validate the output
generateConditionsForPrototypePropertyHitConcurrently after calling it,
since generateConditionsForPrototypePropertyHitConcurrently may return
some weird ObjectConditionSet because of concurrent mutator. If
ObjectConditionSet is weried, installing this means we will
ensure that condition, but that does not mean that it can be usable for
prototype folding. So we should check whether the resulted
ObjectConditionSet is meeting the criteria we would like to guarantee
for prototype folding.
In this case, it is not necessary to strictly align ObjectConditionSet
to what we saw in the first lookup. What we must ensure is the output is
meeting some critical criteria. If they are met, then it is fine.
This patch adds these checks after ObjectConditionSet is created.
* JSTests/stress/dfg-proto-fold-invalidate.js: Added.
(opt):
(main):
* JSTests/stress/dfg-proto-fold-invalidate2.js: Added.
(opt):
(watchCalleeProperty):
(async sleep):
(createClonedArguments):
(async main):
* Source/JavaScriptCore/bytecode/GetByStatus.cpp:
(JSC::GetByStatus::computeFor):
Canonical link: https://commits.webkit.org/297297.455@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.273@webkitglib/2.50
Commit: 99ee81a754ec04524c4700b9224bba535d5616d4
https://github.com/WebKit/WebKit/commit/99ee81a754ec04524c4700b9224bba535d5616d4
Author: Daniel Liu <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
Cherry-pick 297297.469@safari-7622-branch (57746c0c92d0).
https://bugs.webkit.org/show_bug.cgi?id=299313
WasmFunctionParser should reference its signature
https://bugs.webkit.org/show_bug.cgi?id=299313
rdar://159603856
Reviewed by Yijia Huang and Keith Miller.
The WasmFunctionParser needs to ref its signature, or else we could end up
in a state where the signature is referenced by just the FunctionParser.
This patch updates m_signature to become a Ref<>, and edits all uses.
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parse):
(JSC::Wasm::FunctionParser<Context>::parseConstantExpression):
(JSC::Wasm::FunctionParser<Context>::parseBody):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
Canonical link: https://commits.webkit.org/297297.469@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.274@webkitglib/2.50
Commit: a5645a2867e2637a887520adda07dafd9b7a816f
https://github.com/WebKit/WebKit/commit/a5645a2867e2637a887520adda07dafd9b7a816f
Author: Shu-yu Guo <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/wasm/stress/simd-global-v128.js
M Source/JavaScriptCore/wasm/WasmSectionParser.cpp
Log Message:
-----------
Cherry-pick 297297.470@safari-7622-branch (be2f211a40c2).
https://bugs.webkit.org/show_bug.cgi?id=299331
[JSC] Fix Wasm global V128 parsing
https://bugs.webkit.org/show_bug.cgi?id=299331
rdar://161060967
Reviewed by Dan Hecht.
This PR fix Wasm global parsing which assumes that a V128 type always has a
constant vector, while it will only have it for constant SIMD opcodes.
Also fixes a related issue where when parsing SIMD constant initializers,
the
extended SIMD opcode is treated as a non-extension opcode.
* JSTests/wasm/stress/simd-global-v128.js: Added.
Canonical link: https://commits.webkit.org/297297.470@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.275@webkitglib/2.50
Commit: 3175f423b3ccc45938965405e8be6b6e7780267f
https://github.com/WebKit/WebKit/commit/3175f423b3ccc45938965405e8be6b6e7780267f
Author: Claudio Saavedra <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A LayoutTests/fast/html/crash-marquee-fullscreen-expected.txt
A LayoutTests/fast/html/crash-marquee-fullscreen.html
M Source/WebCore/rendering/RenderElement.cpp
Log Message:
-----------
Cherry-pick [email protected] (6a0447375f9d).
https://bugs.webkit.org/show_bug.cgi?id=296869
ASAN_ILL | LayoutIntegration::LineLayout::paint;
WebCore::RenderBlock::paintObject; WebCore::RenderBlock::paint
https://bugs.webkit.org/show_bug.cgi?id=296869
Reviewed by Alan Baradlay.
This crash is caused by how RenderMarquee (which is not an actual render)
handles internally its state. When the marquee is in a seemingly active
state but it has been stopped, RenderMarquee will mark its renderer
as needing layout. However, when the marquee is part of inline content,
this information is not available when the style difference is adjusted --
so it can easily be skipped for layout, creating an inconsistent state
and trigger an assertion after layout has finished and it is detected
that there is still a renderer that is dirty.
Address this by checking in RenderElement::adjustStyleDifference() whether
the renderer is used for a Marquee, in which case we make the difference
include layout as well as any other needed change.
The conditions for this to happen seem to be that the marquee is stopped
early on, nearby elements have to be reparented so as to trigger a rebuild
of the
render tree, and the marquee block renderer ends up as part of inline
content.
In the test case added, the asynchronous fullscreen call forces a relayout
after the conditions are met, so we end up with a dirty render tree after
layout. It seems to be very time-sensitive, hence the test is not so
elegant,
but it's as good as it gets considering it's a reduction from a fuzzing
test case.
* LayoutTests/fast/html/crash-marquee-fullscreen-expected.txt: Added.
* LayoutTests/fast/html/crash-marquee-fullscreen.html: Added.
* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::adjustStyleDifference const):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/297297.472@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.276@webkitglib/2.50
Commit: 1e0576e6baf8d77195287e775d87119ecb698257
https://github.com/WebKit/WebKit/commit/1e0576e6baf8d77195287e775d87119ecb698257
Author: Vassili Bykov <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/wasm/regress/299491.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
Cherry-pick 297297.473@safari-7622-branch (9a6b5549c26a).
https://bugs.webkit.org/show_bug.cgi?id=299491
FunctionParser::resetLocalInitStackToHeight should capture the stack size
before iterating
https://bugs.webkit.org/show_bug.cgi?id=299491
rdar://161097132
Reviewed by Yijia Huang.
The loop is intended to repeat (stackSize - height) times, popping an
element each time.
Because popping an element reduces the current stack size, it should save
the size in a
local variable and use the saved value instead of retrieving it repeatedly
while
iterating.
I'm also using this as an opportunity to make this and a couple of
surrounding multi-line
functions more readable by adding line breaks between them.
Canonical link: https://commits.webkit.org/297297.473@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.277@webkitglib/2.50
Commit: f7b4b1c0c0487d5731d2efa9419d45403bb769f2
https://github.com/WebKit/WebKit/commit/f7b4b1c0c0487d5731d2efa9419d45403bb769f2
Author: Keith Miller <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A LayoutTests/workers/worker-terminate-crash-expected.txt
A LayoutTests/workers/worker-terminate-crash.html
M Source/JavaScriptCore/runtime/JSObject.cpp
Log Message:
-----------
Cherry-pick 297297.475@safari-7622-branch (552426566310).
https://bugs.webkit.org/show_bug.cgi?id=299499
Creating ArrayStorage should DeferTerminationForAWhile during setup
https://bugs.webkit.org/show_bug.cgi?id=299499
rdar://156134962
Reviewed by Yijia Huang.
While converting to ArrayStorage if we handle a termination exception we
can leave the object
in an inconsistent state. We should just DeferTermination while doing this
transisition for
consistency.
Canonical link: https://commits.webkit.org/297297.475@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.278@webkitglib/2.50
Commit: bce391542867cdfe7a502cce1df03ae9a7402fda
https://github.com/WebKit/WebKit/commit/bce391542867cdfe7a502cce1df03ae9a7402fda
Author: Youenn Fablet <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/WebCore/loader/MediaResourceLoader.cpp
Log Message:
-----------
Cherry-pick 297297.477@safari-7622-branch (6cfacf6782cd).
https://bugs.webkit.org/show_bug.cgi?id=299499
Crash under MediaResourceLoader::requestResource()
rdar://161217814
Reviewed by Jean-Yves Avenard.
We add checks to protect from empty URLs.
* Source/WebCore/loader/MediaResourceLoader.cpp:
(WebCore::computeLoadedFromOpaqueSource):
(WebCore::MediaResourceLoader::requestResource):
(WebCore::MediaResourceLoader::redirectReceived):
Canonical link: https://commits.webkit.org/297297.477@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.279@webkitglib/2.50
Commit: fb62cc4d0ae357a30063a9f63f9c75c9b4ef5cae
https://github.com/WebKit/WebKit/commit/fb62cc4d0ae357a30063a9f63f9c75c9b4ef5cae
Author: Ronan Turner <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/WebCore/css/CSSFontFace.cpp
M Source/WebCore/css/CSSFontFace.h
M Source/WebCore/css/CSSFontFaceSource.cpp
M Source/WebCore/css/CSSFontFaceSource.h
M Source/WebCore/css/CSSFontSelector.cpp
M Source/WebCore/loader/cache/CachedFont.cpp
M Source/WebCore/loader/cache/CachedFont.h
M Source/WebCore/platform/graphics/Font.cpp
M Source/WebCore/platform/graphics/Font.h
M Source/WebCore/workers/WorkerFontLoadRequest.cpp
M Source/WebCore/workers/WorkerFontLoadRequest.h
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
M Tools/TestWebKitAPI/Tests/WebKitCocoa/LockdownModeFonts.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/SafeFontParser-Invalid.ttf
A Tools/TestWebKitAPI/Tests/WebKitCocoa/SafeFontParser-Worker.html
Log Message:
-----------
Cherry-pick 297297.479@safari-7622-branch (0d4976340f1d).
https://bugs.webkit.org/show_bug.cgi?id=299511
Ensure SafeFontParser is used more widely.
https://bugs.webkit.org/show_bug.cgi?id=299511
rdar://160955353
Reviewed by Vitor Roriz and Brent Fulgham.
SafeFontParser is adopted either when we enable Lockdown Mode, or when
an explicit setting is set to force it to be used. There were several
cases where we still did not use SafeFontParser for custom fonts - when
creating a font request in a Worker, and primarily when supplying
immediate font sources that did not require a network load.
This adopts SafeFontParser for these cases too and adjusts several calls
to be more explicitly clear in their function.
Testing this is quite tricky as we do not expose anything about being
handled by SafeFontParser. Instead, currently, a canary font is used in
two additional test cases that should fail to parse in SafeFontParser,
but succeeds in FontParser. This allows a proxy measure for identifying
if we've been loaded in SafeFontParser.
* Source/WebCore/css/CSSFontFace.cpp:
(WebCore::CSSFontFace::CSSFontFace):
(WebCore::CSSFontFace::opportunisticallyStartFontDataURLLoading):
(WebCore::CSSFontFace::pump):
(WebCore::CSSFontFace::font):
* Source/WebCore/css/CSSFontFace.h:
* Source/WebCore/css/CSSFontFaceSource.cpp:
(WebCore::CSSFontFaceSource::opportunisticallyStartFontDataURLLoading):
(WebCore::CSSFontFaceSource::loadCustomFont):
(WebCore::CSSFontFaceSource::load):
* Source/WebCore/css/CSSFontFaceSource.h:
* Source/WebCore/css/CSSFontSelector.cpp:
(WebCore::CSSFontSelector::opportunisticallyStartFontDataURLLoading):
* Source/WebCore/loader/cache/CachedFont.cpp:
(WebCore::CachedFont::ensureCustomFontData):
(WebCore::CachedFont::createCustomFontData):
(WebCore::CachedFont::createCustomFontDataWithPolicy):
(WebCore::CachedFont::createCustomFontDataSystemParser):
(WebCore::CachedFont::createCustomFontDataSafeFontParser):
(WebCore::CachedFont::createCustomFontDataExperimentalParser): Deleted.
* Source/WebCore/loader/cache/CachedFont.h:
* Source/WebCore/platform/graphics/Font.cpp:
(WebCore::Font::create):
* Source/WebCore/platform/graphics/Font.h:
* Source/WebCore/workers/WorkerFontLoadRequest.cpp:
(WebCore::WorkerFontLoadRequest::loadCustomFont):
(WebCore::WorkerFontLoadRequest::ensureCustomFontData):
* Source/WebCore/workers/WorkerFontLoadRequest.h:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/LockdownModeFonts.mm:
(TestWebKitAPI::EncodeResourceAsArrayString):
(TestWebKitAPI::TEST(LockdownMode, NotAllowedFontLoadingAPI)):
(TestWebKitAPI::TEST(LockdownMode, AllowedFontLoadingAPI)):
(TestWebKitAPI::TEST(LockdownMode, NotSupportedFontLoadingAPI)):
(TestWebKitAPI::TEST(LockdownMode,
DISABLED_ImmediateParsedViaSafeFontParser)):
(TestWebKitAPI::TEST(LockdownMode,
DISABLED_CanaryFontSucceedsInFontParser)):
(TestWebKitAPI::TEST(LockdownMode,
DISABLED_WorkerFontParsedViaSafeFontParser)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SafeFontParser-Invalid.ttf: Added.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SafeFontParser-Worker.html: Added.
Canonical link: https://commits.webkit.org/297297.479@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.280@webkitglib/2.50
Commit: 649b9350a9c4c2c3db982ba154f72374d9468855
https://github.com/WebKit/WebKit/commit/649b9350a9c4c2c3db982ba154f72374d9468855
Author: Daniel Liu <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
M Source/bmalloc/bmalloc/TZoneHeapManager.cpp
Log Message:
-----------
Cherry-pick 297297.481@safari-7622-branch (4d7b31cea437).
https://bugs.webkit.org/show_bug.cgi?id=299486
Strengthen TZone bucket allocation randomization
https://bugs.webkit.org/show_bug.cgi?id=299486
rdar://157014281
Reviewed by Keith Miller.
This patch strengthens TZone's bucket allocation randomization by utilizing
HMAC instead of a PRNG. For systems without CommonCrypto, the fallback is a
PRNG.
* Source/bmalloc/bmalloc/TZoneHeapManager.cpp:
(bmalloc::api::TZoneHeapManager::tzoneBucketForKey):
Canonical link: https://commits.webkit.org/297297.481@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.281@webkitglib/2.50
Commit: 9b821c0cc81f3f1158441f198efba596c23bf022
https://github.com/WebKit/WebKit/commit/9b821c0cc81f3f1158441f198efba596c23bf022
Author: Dan Hecht <[email protected]>
Date: 2025-11-10 (Mon, 10 Nov 2025)
Changed paths:
A JSTests/wasm/stress/ipint-bbq-osr-check-try-implicit-slot-overlap2.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
Log Message:
-----------
Cherry-pick d37b918c6ed2. https://bugs.webkit.org/show_bug.cgi?id=300350
[JSC] BBQ does not have implicit exception slot inside Try
https://bugs.webkit.org/show_bug.cgi?id=300350
rdar://158848294
Reviewed by Yusuke Suzuki.
Follow up to 297297.400@safari-7622-branch: do not access
BBQJIT::exception() for Try blocks, and fill the Void stack map
entry with a zero constant so that loadValuesIntoBuffer() will
zero fill this placeholder slot when constructing the scratch buffer
for BBQ -> OMG loop OSR.
* JSTests/wasm/stress/ipint-bbq-osr-check-try-implicit-slot-overlap2.js:
Added.
(instantiate):
(async let.fn0):
(let.fn1):
(let.fn2):
(let.fn3):
(let.fn4):
(let.fn5):
(async let):
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::exception):
(JSC::Wasm::BBQJITImpl::BBQJIT::makeStackMap):
Canonical link: https://commits.webkit.org/297297.520@safari-7622-branch
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.282@webkitglib/2.50
Compare: https://github.com/WebKit/WebKit/compare/9ddc37ff3fa3...9b821c0cc81f
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
