Branch: refs/heads/webkitglib/2.50
Home: https://github.com/WebKit/WebKit
Commit: a044c22c34f25429049e8336a5ef0e4297ff8e46
https://github.com/WebKit/WebKit/commit/a044c22c34f25429049e8336a5ef0e4297ff8e46
Author: Adrian Perez de Castro <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M Source/WebKit/UIProcess/API/wpe/WPEWebViewPlatform.cpp
Log Message:
-----------
Fix the build after 298234.475@webkitglib/2.50
Unreviewed build fix.
* Source/WebKit/UIProcess/API/wpe/WPEWebViewPlatform.cpp:
(WKWPE::ViewPlatform::handleGesture): Use the correct name for
Phase::PhaseEnded.
Canonical link: https://commits.webkit.org/298234.481@webkitglib/2.50
Commit: 2d458619628e8b6e63b569fb5985d2759920b775
https://github.com/WebKit/WebKit/commit/2d458619628e8b6e63b569fb5985d2759920b775
Author: Keith Miller <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
A JSTests/stress/array-allocation-elimination-closure-capture.js
A JSTests/stress/array-allocation-elimination-conditional-usage.js
A JSTests/stress/array-allocation-elimination-cross-function.js
A
JSTests/stress/array-allocation-elimination-loop-unroll-materialize-at-osr.js
A JSTests/stress/array-allocation-sink-with-osr-exit-materialization.js
A
JSTests/stress/array-sink-osr-materialization-self-reference-in-butterfly.js
A JSTests/stress/array-sink-osr-materialization.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp
M Source/JavaScriptCore/dfg/DFGClobberize.h
M Source/JavaScriptCore/dfg/DFGCloneHelper.h
M Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp
M Source/JavaScriptCore/dfg/DFGDoesGC.cpp
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
M Source/JavaScriptCore/dfg/DFGLoopUnrollingPhase.cpp
M Source/JavaScriptCore/dfg/DFGMayExit.cpp
M Source/JavaScriptCore/dfg/DFGNode.cpp
M Source/JavaScriptCore/dfg/DFGNode.h
M Source/JavaScriptCore/dfg/DFGNodeType.h
M Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp
M Source/JavaScriptCore/dfg/DFGObjectMaterializationData.h
M Source/JavaScriptCore/dfg/DFGOperations.cpp
M Source/JavaScriptCore/dfg/DFGOperations.h
M Source/JavaScriptCore/dfg/DFGPredictionPropagationPhase.cpp
M Source/JavaScriptCore/dfg/DFGPromotedHeapLocation.h
M Source/JavaScriptCore/dfg/DFGSafeToExecute.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
M Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp
M Source/JavaScriptCore/dfg/DFGUseKind.h
M Source/JavaScriptCore/dfg/DFGValidate.cpp
M Source/JavaScriptCore/ftl/FTLCapabilities.cpp
M Source/JavaScriptCore/ftl/FTLExitTimeObjectMaterialization.cpp
M Source/JavaScriptCore/ftl/FTLExitTimeObjectMaterialization.h
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/ftl/FTLOperations.cpp
M Source/JavaScriptCore/ftl/FTLOperations.h
M Source/JavaScriptCore/runtime/IndexingType.cpp
M Source/JavaScriptCore/runtime/IndexingType.h
Log Message:
-----------
Cherry-pick c3b478c1983f. https://bugs.webkit.org/show_bug.cgi?id=298606
Array allocation sinking should split allocations into two, an Array
allocation and a Butterfly allocation
rdar://159207754
https://bugs.webkit.org/show_bug.cgi?id=298606
Reviewed by Yusuke Suzuki.
This patch minorly rearchitects how we do Array allocation sinking in DFG.
Previously we tried to model Arrays
in ObjectAllocationSinking as two allocations one where the actual Array
was allocated and a "Butterfly"
at each `GetButterfly`. This meant that there was now a reverse data
dependency between the GetButterfly and
the Array allocation Nodes. This was a little unintuitive but also meant
that any control flow that would
merge two `GetButterfly`s would escape the Array.
This PR simplifies things by more directly representing the heap in
ObjectAllocationSinking. There are now
two nodes that get sunk when sinking an Array: NewButterflyWithSize and
NewArrayWithButterfly. All the
indexed properties and the Butterfly's location are stored on the
NewArrayWithButterfly's Allocation.
The NewButterflyWithSize only contains the Array's length. If we ever
wanted to extend Array allocation sinking
to support out of bounds stores we'd have to teach `handleNode` how to deal
with writes to multiple allocations.
Originally I had all the indexed properties and the length are stored on
the LocalHeap of NewButterflyWithSize and
NewArrayWithButterfly's LocalHeap only contains the butterfly. But I
realized that we crash while trying to materialize
a phantom array that contains itself or another newly materialized object
that's in a cycle. This is because we have to
materialize the pointer as a PutByVal. We can't emit this PutByVal without
the Array since we need to write barrier after
the store.
Overall, this change is perf neutral or maybe a slight progression on
JetStream 3.
Canonical link: https://commits.webkit.org/300129@main
Canonical link: https://commits.webkit.org/297297.440@safari-7622-branch
Canonical link: https://commits.webkit.org/298234.482@webkitglib/2.50
Commit: ab2d9590884e8c373db6e203452cc3f7676eec15
https://github.com/WebKit/WebKit/commit/ab2d9590884e8c373db6e203452cc3f7676eec15
Author: Shu-yu Guo <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
A JSTests/stress/private-names-seal-freeze.js
M Source/JavaScriptCore/runtime/PropertyTable.cpp
Log Message:
-----------
Cherry-pick 308512@main (672cdd38781c).
https://bugs.webkit.org/show_bug.cgi?id=303357
[JSC] Don't set attributes on private fields when sealing/freezing
https://bugs.webkit.org/show_bug.cgi?id=303357
rdar://165252763
Reviewed by Yusuke Suzuki and Mark Lam.
This PR makes it such that when sealing and freezing objects, entries in the
PropertyTable that are private fields do not change their attributes.
Private
fields are not properties from the spec's point of view, and thus don't have
attributes.
Ensuring private field entries simplifies assumptions in the JITs, as they
can
assume having attributes when setting a property results in a structure
transition.
Test: JSTests/stress/private-names-seal-freeze.js
Originally-landed-as: 301765.343@safari-7623-branch (b6b02057f0c4).
rdar://171560076
Canonical link: https://commits.webkit.org/308512@main
Canonical link: https://commits.webkit.org/298234.483@webkitglib/2.50
Commit: ec19743d6eecff724bf2106f0ff5667d02dd2ac0
https://github.com/WebKit/WebKit/commit/ec19743d6eecff724bf2106f0ff5667d02dd2ac0
Author: Aditya Keerthi <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/html/interaction/focus/sequential-focus-navigation-after-disabled-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/html/interaction/focus/sequential-focus-navigation-after-disabled.html
M LayoutTests/platform/ios/TestExpectations
M Source/WebCore/page/Page.cpp
Log Message:
-----------
Cherry-pick 308991@main (487ec443bd23).
https://bugs.webkit.org/show_bug.cgi?id=309544
REGRESSION (260067@main): Tabbing position lost when button is disabled
https://bugs.webkit.org/show_bug.cgi?id=309544
rdar://120676409
Reviewed by Ryosuke Niwa and Abrar Rahman Protyasha.
260067@main implemented the focus fixup rule to clear focus from an element
that is no longer focusable (e.g. a button that became disabled). This
change
also had the effect of resetting the sequential focus navigation starting
point.
Consequently, the next Tab key press started focus navigation from the
beginning of the document instead of advancing from where the disabled
element
was.
Fix by preserving the sequential focus navigation starting point by
resetting
it to the now-unfocusable element after clearing focus, the same way the
element-removal code path already does.
*
LayoutTests/imported/w3c/web-platform-tests/html/interaction/focus/sequential-focus-navigation-after-disabled-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/html/interaction/focus/sequential-focus-navigation-after-disabled.html:
Added.
* LayoutTests/platform/ios/TestExpectations:
* Source/WebCore/page/Page.cpp:
(WebCore::Page::updateRendering):
Canonical link: https://commits.webkit.org/308991@main
Canonical link: https://commits.webkit.org/298234.484@webkitglib/2.50
Commit: 556a4ae7cfd44e45f0ee525e1751e87c76be412c
https://github.com/WebKit/WebKit/commit/556a4ae7cfd44e45f0ee525e1751e87c76be412c
Author: Simon Fraser <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
A
LayoutTests/http/tests/navigation-api/scroll-offset-after-navigation-back-expected.html
A
LayoutTests/http/tests/navigation-api/scroll-offset-after-navigation-back.html
M Source/WebCore/page/NavigateEvent.cpp
Log Message:
-----------
Cherry-pick 308976@main (63798105bff3).
https://bugs.webkit.org/show_bug.cgi?id=309542
Pages using the Navigation API sometimes have offset hit test locations
https://bugs.webkit.org/show_bug.cgi?id=309542
rdar://171752650
Reviewed by Abrar Rahman Protyasha.
Navigation API was calling `LocalFrameView::scrollTo()`, which bypasses the
normal async
scrolling `requestScrollPositionUpdate` machinery; there's a comment in
ScrollView.h about
not calling this function. This could result in UI and web processes having
different
scroll offsets.
Fix by having NavigateEvent call `setScrollPosition` instead.
Test: http/tests/navigation-api/scroll-offset-after-navigation-back.html
*
LayoutTests/http/tests/navigation-api/scroll-offset-after-navigation-back-expected.html:
Added.
*
LayoutTests/http/tests/navigation-api/scroll-offset-after-navigation-back.html:
Added.
* Source/WebCore/page/NavigateEvent.cpp:
(WebCore::NavigateEvent::processScrollBehavior):
Canonical link: https://commits.webkit.org/308976@main
Canonical link: https://commits.webkit.org/298234.485@webkitglib/2.50
Commit: 67231e9f4dd3254ee7f52bbfae382aa782f80c89
https://github.com/WebKit/WebKit/commit/67231e9f4dd3254ee7f52bbfae382aa782f80c89
Author: Adrian Perez de Castro <[email protected]>
Date: 2026-03-12 (Thu, 12 Mar 2026)
Changed paths:
M Source/WebKit/wpe/NEWS
M Source/cmake/OptionsWPE.cmake
Log Message:
-----------
Unreviewed. Update OptionsWPE.cmake and NEWS for the 2.50.6 release
* Source/WebKit/wpe/NEWS: Add release notes.
* Source/cmake/OptionsWPE.cmake: Bump version numbers.
Canonical link: https://commits.webkit.org/298234.486@webkitglib/2.50
Commit: 2f4b9f5df4bf7c03db37dfa3370801f2933b0495
https://github.com/WebKit/WebKit/commit/2f4b9f5df4bf7c03db37dfa3370801f2933b0495
Author: Rupin Mittal <[email protected]>
Date: 2026-03-12 (Thu, 12 Mar 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
Log Message:
-----------
Cherry-pick 309114@main (f43860e90c4c).
https://bugs.webkit.org/show_bug.cgi?id=309695
StabilityTracer: Crash in callback of async IPC sent by
WebKit::NetworkProcess::findPendingDownloadLocation
https://bugs.webkit.org/show_bug.cgi?id=309695
rdar://172248665
Reviewed by Ben Nham and Per Arne Vollan.
It looks like the crash is due to a null pointer deference. It seems like
the
completion handler on this line:
return completionHandler(PolicyAction::Ignore);
in NetworkProcess::findPendingDownloadLocation is null.
This completion handler is called as part of the reply of the async IPC to
sent to
DownloadProxy::DecideDestinationWithSuggestedFilename.
Given that NetworkProcess::findPendingDownloadLocation receives the
completionHandler
as an rvalue reference and then moves it into the lambda, it's likely not
null to
begin with. But the IPC message is sent with the IPC::Connection* returned
by
downloadProxyConnection(), which can be a nullptr. That would cause
undefined behavior
and could result in this crash.
So we speculatively fix this by early returning if the connection doesn't
exist.
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::findPendingDownloadLocation):
Canonical link: https://commits.webkit.org/309114@main
Canonical link: https://commits.webkit.org/298234.487@webkitglib/2.50
Commit: 5684ce692e2ecc276feb14c790228ad8512e3272
https://github.com/WebKit/WebKit/commit/5684ce692e2ecc276feb14c790228ad8512e3272
Author: Claudio Saavedra <[email protected]>
Date: 2026-03-12 (Thu, 12 Mar 2026)
Changed paths:
M Source/WebKit/UIProcess/wpe/WebPageProxyWPE.cpp
Log Message:
-----------
Cherry-pick 309127@main (f52e977c469e).
https://bugs.webkit.org/show_bug.cgi?id=289436
REGRESSION(291846@main) [WPE] /webkit/WebKitWebView/save is crashing
https://bugs.webkit.org/show_bug.cgi?id=289436
Reviewed by Fujii Hironori.
WebPageProxy::callAfterNextPresentationUpdate() was not calling the
completion handler in the callback agreggator if there was no page
client. Calling it in that case seems to fix this crash.
Test: Covered by existing tests.
* Source/WebKit/UIProcess/wpe/WebPageProxyWPE.cpp:
(WebKit::WebPageProxy::callAfterNextPresentationUpdate):
* Tools/TestWebKitAPI/glib/TestExpectations.json:
Canonical link: https://commits.webkit.org/309127@main
Canonical link: https://commits.webkit.org/298234.488@webkitglib/2.50
Commit: f1f95ad015323dba01313fd2da79fc251edafdf0
https://github.com/WebKit/WebKit/commit/f1f95ad015323dba01313fd2da79fc251edafdf0
Author: Fujii Hironori <[email protected]>
Date: 2026-03-12 (Thu, 12 Mar 2026)
Changed paths:
M Source/WebKit/WPEPlatform/wpe/wayland/WPEToplevelWayland.cpp
Log Message:
-----------
Cherry-pick 309135@main (d22d04217d84).
https://bugs.webkit.org/show_bug.cgi?id=309763
[WPE] AddressSanitizer: heap-buffer-overflow in WPEToplevelWayland.cpp
https://bugs.webkit.org/show_bug.cgi?id=309763
Reviewed by Claudio Saavedra.
The member `size` of wl_array is in bytes. It should be divided by the item
size.
Co-authored-by: Simon Pena <[email protected]>
* Source/WebKit/WPEPlatform/wpe/wayland/WPEToplevelWayland.cpp:
Canonical link: https://commits.webkit.org/309135@main
Canonical link: https://commits.webkit.org/298234.489@webkitglib/2.50
Commit: 9c4a0bc0b10985c487ba8e269de6607a471bfee3
https://github.com/WebKit/WebKit/commit/9c4a0bc0b10985c487ba8e269de6607a471bfee3
Author: Youenn Fablet <[email protected]>
Date: 2026-03-12 (Thu, 12 Mar 2026)
Changed paths:
A LayoutTests/http/wpt/fetch/resources/wrong-form-data.py
A LayoutTests/http/wpt/fetch/wrong-form-data-expected.txt
A LayoutTests/http/wpt/fetch/wrong-form-data.html
M Source/WebCore/Modules/fetch/FetchBodyConsumer.cpp
Log Message:
-----------
Cherry-pick 309130@main (ff70c312f1bb).
https://bugs.webkit.org/show_bug.cgi?id=309676
Parsing multipart form data should check that the boundary is followed by
CRLF or "--"
rdar://172038722
https://bugs.webkit.org/show_bug.cgi?id=309676
Reviewed by Chris Dumez.
We make sure that the parser checks that next two bytes after the boundary
are either '--' or crlf.
Otherwise, we bail out and form data parsing fails.
Covered by added test.
Canonical link: https://commits.webkit.org/309130@main
Canonical link: https://commits.webkit.org/298234.490@webkitglib/2.50
Commit: fd02d1fc7c7bb3834e9e081a5315b65a60979f62
https://github.com/WebKit/WebKit/commit/fd02d1fc7c7bb3834e9e081a5315b65a60979f62
Author: Adrian Perez de Castro <[email protected]>
Date: 2026-03-12 (Thu, 12 Mar 2026)
Changed paths:
M Source/WebKit/gtk/NEWS
M Source/cmake/OptionsGTK.cmake
Log Message:
-----------
Unreviewed. Update OptionsGTK.cmake and NEWS for the 2.50.6 release
* Source/WebKit/gtk/NEWS: Add release notes.
* Source/cmake/OptionsGTK.cmake: Bump version numbers.
Canonical link: https://commits.webkit.org/298234.491@webkitglib/2.50
Compare: https://github.com/WebKit/WebKit/compare/791fabbcf2cc...fd02d1fc7c7b
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
