Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 943cd9fd9d909a4019f4d840fdda8619bd611358
https://github.com/WebKit/WebKit/commit/943cd9fd9d909a4019f4d840fdda8619bd611358
Author: Frédéric Wang <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
A
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts4-expected.txt
A LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts4.html
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Bug 300371 [WebKit][Main+SU?] [e4d4086839401519] ASAN_ILL |
WTF::HashTable::lookup; WebCore::RenderBlockFlow::layoutBlockChildren;
WebCore::RenderBlockFlow::layoutBlock
rdar://162032638
Reviewed by Alan Baradlay.
Skipped root/subtree may not have their m_floatingObjects up-to-date.
In particular this set may contain dangling pointer to destroyed renderers
causing some null pointer dereference when marking siblings/descendants
with floats for layout. This patch fixes that using the logic of (*):
we always enter skipped root/subtree when marking for layout and at the
same time skip calls to containsFloat()/removeFloatingBox().
(*) https://commits.webkit.org/293889@main.
*
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts4-expected.txt:
Added.
* LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts4.html:
Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::isSkippedContentRootOrSkippedContent): New helper method to test both
skipped content root and subtree.
(WebCore::RenderBlockFlow::layoutBlockChildren): Force to descend into the
subtree for skipped root/subtree and don't call containsFloat() on a possible
dirty m_floatingObjects.
(WebCore::RenderBlockFlow::markAllDescendantsWithFloatsForLayout): Don't call
removeFloatingBox() on a possibly dirty m_floatingObjects.
Instead mark the renderer as skipped during layout so that it will be rebuilt
later.
Force to descend into the subtree for skipped root/subtree.
(WebCore::RenderBlockFlow::markSiblingsWithFloatsForLayout): Rewrite the code
from (*) using the new helper.
Originally-landed-as: [email protected] (e26b1271204e).
rdar://166339384
Canonical link: https://commits.webkit.org/304407@main
Commit: a351a136f1247124fe9b48b5cc7e1ffd43549871
https://github.com/WebKit/WebKit/commit/a351a136f1247124fe9b48b5cc7e1ffd43549871
Author: Said Abou-Hallawa <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
A LayoutTests/ipc/convert-to-luminance-mask-float16-expected.txt
A LayoutTests/ipc/convert-to-luminance-mask-float16.html
M Source/WebCore/platform/graphics/ImageBufferBackend.cpp
M Source/WebCore/platform/graphics/ImageBufferBackend.h
Log Message:
-----------
[CoreIPC] convertToLuminanceMask() is not ready to work in backend with
RGBA16F pixel format
https://bugs.webkit.org/show_bug.cgi?id=300049
rdar://161079211
Reviewed by Gerald Squelart.
CoreIPC can create a RemoteImageBuffer with RGBA16F pixel format then it can
call
convertToLuminanceMask() for it. Currently convertToLuminanceMask() calculates
four bytes per pixel. It also deals with standard colorSpace which assumes all
the channels range from 0 to 1.
The fix is convertToLuminanceMask() should work only for 4-bytes buffers for
now.
Test: ipc/convert-to-luminance-mask-float16.html
* LayoutTests/ipc/convert-to-luminance-mask-float16-expected.txt: Added.
* LayoutTests/ipc/convert-to-luminance-mask-float16.html: Added.
* Source/WebCore/platform/graphics/ImageBufferBackend.cpp:
(WebCore::ImageBufferBackend::convertToLuminanceMaskFloat16):
(WebCore::ImageBufferBackend::convertToLuminanceMaskUint8):
(WebCore::ImageBufferBackend::convertToLuminanceMask):
* Source/WebCore/platform/graphics/ImageBufferBackend.h:
Originally-landed-as: 301765.69@safari-7623-branch (dd5d2b7d6a4c).
rdar://166339235
Canonical link: https://commits.webkit.org/304408@main
Commit: e03b456698eabb3dcd7ba3ae9ba6bf18cd767b1a
https://github.com/WebKit/WebKit/commit/e03b456698eabb3dcd7ba3ae9ba6bf18cd767b1a
Author: Dan Hecht <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
A JSTests/wasm/stress/i32-multivalue-truncate.js
M Source/JavaScriptCore/wasm/WasmOperations.cpp
Log Message:
-----------
[JSC] operationIterateResults needs to truncate i32 results
https://bugs.webkit.org/show_bug.cgi?id=301211
rdar://153280651
Reviewed by Daniel Liu.
BBQ expects that values are truncated to their proper size when
producing the value. When converting from JS signed 32-bits to
wasm i32, should be zero extending rather than sign extending.
Test: JSTests/wasm/stress/i32-multivalue-truncate.js
* JSTests/wasm/stress/i32-multivalue-truncate.js: Added.
(async test.getTwoI32s):
(async test):
* Source/JavaScriptCore/wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_NOEXCEPT_JIT_OPERATION):
Originally-landed-as: 301765.80@safari-7623-branch (dad39caa1d1c).
rdar://166339272
Canonical link: https://commits.webkit.org/304409@main
Commit: 9326bbd1cf1f7d3af0490338a98d1cf6544ad725
https://github.com/WebKit/WebKit/commit/9326bbd1cf1f7d3af0490338a98d1cf6544ad725
Author: Sihui Liu <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
M Source/WebCore/Modules/indexeddb/IDBTransaction.cpp
M Source/WebCore/Modules/indexeddb/IDBTransaction.h
Log Message:
-----------
Fix use-after-free in IDBTransaction::abortInProgressOperations
rdar://161012400
Reviewed by Per Arne Vollan.
Recent crashes indicate that the objects in
m_transactionOperationsInProgressQueue are already freed when we try to
create RefPtr from them in IDBTransaction::abortInProgressOperations. To fix
this, store RefPtr in
m_transactionOperationsInProgressQueue.
* Source/WebCore/Modules/indexeddb/IDBTransaction.cpp:
(WebCore::IDBTransaction::abortInProgressOperations):
* Source/WebCore/Modules/indexeddb/IDBTransaction.h:
Originally-landed-as: 301765.81@safari-7623-branch (c819f0eceb0a).
rdar://166339113
Canonical link: https://commits.webkit.org/304410@main
Commit: ef1aba9e847aa7b67170048992bdfee68855728e
https://github.com/WebKit/WebKit/commit/ef1aba9e847aa7b67170048992bdfee68855728e
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-12 (Fri, 12 Dec 2025)
Changed paths:
A JSTests/stress/data-view-byte-length-oob-exit.js
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
[JSC] DataViewGetByteLength resizable-array path is not setting OSR exit
correctly
https://bugs.webkit.org/show_bug.cgi?id=301257
rdar://160383983
Reviewed by Tadeu Zagallo.
There are two issues in the implementation of resizable-array-accepting
DataViewGetByteLength. This is because this node is specially doing OSR
exit from a patchpoint. And other patchpoints are typically (1) not
having a result value and not having a complicated computation or (2)
OSR exits only when exception is thrown and exception-related-OSR-exit
is handled in a different way. This patch fixes DataViewGetByteLength
patchpoint by introducing two changes.
1. resultGPR can be modified before jumping to OSR exit. This is
problematic since OSR exit's stackmap is capturing what we see before
this patchpoint starts. We should def the result only after ensuring
that we will not do OSR exit. This patch adds one scratch register
and storing a result to that. And after OSR exit check is done, we
move it to the resultGPR.
2. osrExitArgumentOffset is not correct as it requires result value
offset. Adding +1 to that offset.
Test: JSTests/stress/data-view-byte-length-oob-exit.js
* JSTests/stress/data-view-byte-length-oob-exit.js: Added.
(i.counter.else.catch):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::typedArrayLength):
Originally-landed-as: 301765.85@safari-7623-branch (2432c9cc358a).
rdar://166338914
Canonical link: https://commits.webkit.org/304411@main
Compare: https://github.com/WebKit/WebKit/compare/39a5ac271398...ef1aba9e847a
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
