Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 7a2b71d0014f0b661cbaf9a04efc50dec769d094
https://github.com/WebKit/WebKit/commit/7a2b71d0014f0b661cbaf9a04efc50dec769d094
Author: Rupin Mittal <[email protected]>
Date: 2026-04-16 (Thu, 16 Apr 2026)
Changed paths:
M
Source/WebKit/NetworkProcess/ServiceWorker/ServiceWorkerNavigationPreloader.cpp
Log Message:
-----------
Cherry-pick 311165@main (4e1728b58249).
https://bugs.webkit.org/show_bug.cgi?id=312219
StabilityTracer: Crash in NetworkProcess::findPendingDownloadLocation
https://bugs.webkit.org/show_bug.cgi?id=312219
rdar://174045941
Reviewed by Chris Dumez.
NetworkProcess::findPendingDownloadLocation passes a lambda to
DownloadProxy::DecideDestinationWithSuggestedFilename which contians a
completionHandler. When this completionHandler is called, we crash because
the
underlying function is null. It's possible that when the completionHandler
was passed in to NetworkProcess::findPendingDownloadLocation(), it was
already
null.
One of the ways this completionHandler ends up here is:
1. DownloadManager::convertNetworkLoadToDownload()
2. PendingDownload::PendingDownload()
3. NetworkLoad::convertTaskToDownload()
4. NetworkProcess::findPendingDownloadLocation()
There are three callsites to convertNetworkLoadToDownload() that pass in a
completionHandler. One of them constructs the completionHandler right before
passing it in. The other null checks the completionHandler before passing it
in. The third callsite,
ServiceWorkerNavigationPreloader::convertToDownload(),
does neither.
So, as a speculative fix, we amend the this third callsite to null check its
completionHandler before passing it to convertNetworkLoadToDownload().
*
Source/WebKit/NetworkProcess/ServiceWorker/ServiceWorkerNavigationPreloader.cpp:
(WebKit::ServiceWorkerNavigationPreloader::convertToDownload):
Canonical link: https://commits.webkit.org/311165@main
Canonical link: https://commits.webkit.org/305877.435@webkitglib/2.52
Commit: 1f33d1908da09ad328f7efcc4b1eeca62d1b6c77
https://github.com/WebKit/WebKit/commit/1f33d1908da09ad328f7efcc4b1eeca62d1b6c77
Author: Tyler Wilcock <[email protected]>
Date: 2026-04-16 (Thu, 16 Apr 2026)
Changed paths:
A LayoutTests/accessibility/aria-labelledby-cycle-multi-element-expected.txt
A LayoutTests/accessibility/aria-labelledby-cycle-multi-element.html
M Source/WebCore/accessibility/AccessibilityNodeObject.cpp
Log Message:
-----------
Cherry-pick 311172@main (a7d0c4715931).
https://bugs.webkit.org/show_bug.cgi?id=312187
AX: Resolving aria-labelledby and aria-describedby can cause infinite
recursion, eventually crashing
https://bugs.webkit.org/show_bug.cgi?id=312187
rdar://174683836
Reviewed by Chris Fleizach.
The accessible name computation had no recursion guard against cycles
involving 3+ elements. The existing ignoredChildNode guard only prevented
direct 2-element cycles. Cycles through intermediary elements bypassed it
because each descriptionForElements call created a fresh
TextUnderElementMode
with a different ignoredChildNode.
Added a visited-element set (via static NeverDestroyed<HashSet>) to both
ariaLabeledByAttribute() and ariaDescribedByAttribute(). If we re-enter
either function for an element already being resolved, we return an empty
string, breaking the cycle. This follows the W3C accname spec: "If the
current node is already part of an aria-labelledby traversal, do not
follow its aria-labelledby."
*
LayoutTests/accessibility/aria-labelledby-cycle-multi-element-expected.txt:
Added.
* LayoutTests/accessibility/aria-labelledby-cycle-multi-element.html: Added.
* Source/WebCore/accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::ariaDescribedByAttribute const):
(WebCore::AccessibilityNodeObject::ariaLabeledByAttribute const):
Canonical link: https://commits.webkit.org/311172@main
Canonical link: https://commits.webkit.org/305877.436@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/a4380724fc1f...1f33d1908da0
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
