Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 22684bbb9321e60115f0397bdfc77eb8abca61bd
https://github.com/WebKit/WebKit/commit/22684bbb9321e60115f0397bdfc77eb8abca61bd
Author: Philippe Normand <[email protected]>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
M Source/WebCore/platform/glib/UserAgentQuirks.cpp
M Tools/TestWebKitAPI/Tests/WebCore/UserAgentQuirks.cpp
Log Message:
-----------
Cherry-pick 312508@main (80b3082d0146).
https://bugs.webkit.org/show_bug.cgi?id=313813
[WPE][GTK] Add a user-agent quirk for disney+
https://bugs.webkit.org/show_bug.cgi?id=313813
Reviewed by Carlos Garcia Campos.
Without this quirk only Fairplay DRM is attempted when trying to play DRM
content, because we would
be detected as a Safari UA. By faking a Firefox UA the page might prompt
for more DRM systems, such
as Widevine.
* Source/WebCore/platform/glib/UserAgentQuirks.cpp:
(WebCore::urlRequiresFirefoxBrowser):
Canonical link: https://commits.webkit.org/312508@main
Canonical link: https://commits.webkit.org/305877.469@webkitglib/2.52
Commit: 23c92463651b8d38d616e449d97205a52e515c2b
https://github.com/WebKit/WebKit/commit/23c92463651b8d38d616e449d97205a52e515c2b
Author: Razvan Caliman <[email protected]>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
M Source/WebCore/inspector/agents/InspectorLayerTreeAgent.cpp
M Source/WebInspectorUI/UserInterface/Controllers/LayerTreeManager.js
Log Message:
-----------
Cherry-pick 312435@main (95810670932e).
https://bugs.webkit.org/show_bug.cgi?id=307431
Navigating with the Layers inspector tab open breaks the visualization
https://bugs.webkit.org/show_bug.cgi?id=307431
rdar://170836910
Reviewed by Devin Rousso and Qianlang Chen.
There's a race condition that occurs between backend and frontend during
page reload/navigation
while the Layers tab is open resulting in requesting layer snapshots for
layers that have been
resized to zero during the transition.
Page navigation triggers a `WI.LayerTreeManager.Event.LayerTreeDidChange`
event which
`WI.Layers3DContentView.prototype._layerTreeDidChange` handles by causing
layout of the Layers tab.
Layout fetches layers via
`WI.Layers3DContentView.prototype.layersForNode()`. At this point,
layers exist and have valid sizes. Then for each layer, the frontend calls:
`_populateLayerGroup()` → `_loadLayerTexture()` → `snapshotForLayer()`.
The request for snapshot sends `LayerTreeAgent.requestContent` to the
backend. But, during the
navigation, the render tree has changed: layers may have been destroyed,
lost their compositing backing,
lost their graphics layer, or resized to zero during the transition.
All states throw errors in `InspectorLayerTreeAgent::requestContent`.
The zero-size case is common because, during navigation, the new page's
render tree initially creates
layers with zero dimensions before layout runs.
The error returned by the backend is handled by calling the callback to
`snapshotForLayer()` with `null`
which is a case handled further down the call chain in
`WI.Layers3DContentView.prototype._loadLayerTexture()`.
This is only an issue in Engineering / Debug builds of Web Inspector where
`WI.reportInternalError(error)` surfaces the exception. In release builds,
the `null` case is silently handled.
This patch changes the backend to return an empty string instead of
throwing an error for zero-size layers
given how common the case is during page navigation and that zero-sized
layers aren't really an error state.
The issue itself is transient because during reload/navigation, more layer
tree change events are dispatched.
The compositing update that resized layers to zero isn't the last one. When
the new page finishes loading and layout,
`RenderLayerCompositor::updateCompositingLayers` runs again, firing another
event.
The failed snapshot from the transitional state just results in
`callback(null)` in
`WI.Layers3DContentView.prototype._loadLayerTexture`, which means no
texture is applied to that layer group.
Then, the next successful cycle replaces it with the correct textured mesh.
The zero-size layer error only hits during the intermediate state. The
final stable state always produces a clean pass.
* Source/WebCore/inspector/agents/InspectorLayerTreeAgent.cpp:
(WebCore::InspectorLayerTreeAgent::requestContent):
* Source/WebInspectorUI/UserInterface/Controllers/LayerTreeManager.js:
(WI.LayerTreeManager.prototype.snapshotForLayer):
Canonical link: https://commits.webkit.org/312435@main
Canonical link: https://commits.webkit.org/305877.470@webkitglib/2.52
Commit: 306ced7208c5521d1157324f3538fd61210544b9
https://github.com/WebKit/WebKit/commit/306ced7208c5521d1157324f3538fd61210544b9
Author: Tyler Wilcock <[email protected]>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
A LayoutTests/accessibility/aria-hidden-deep-dom-no-crash-expected.txt
A LayoutTests/accessibility/aria-hidden-deep-dom-no-crash.html
M Source/WebCore/accessibility/AXCoreObject.h
Log Message:
-----------
Cherry-pick 311611@main (e22f4427f1ee).
https://bugs.webkit.org/show_bug.cgi?id=312780
AX: Convert recursive descendant traversal functions to iterative to
prevent stack overflow
https://bugs.webkit.org/show_bug.cgi?id=312780
rdar://172861598
Reviewed by Joshua Hoffman.
enumerateDescendantsIncludingIgnored, findUnignoredDescendant, and
enumerateUnignoredDescendants used unbounded recursion to traverse the
accessibility tree. This could cause stack overflow in two scenarios:
1. JavaScript constructs a deeply nested DOM (e.g. via appendChild) and
toggles aria-hidden, recomputeIsIgnoredForDescendants calls
enumerateDescendantsIncludingIgnored,
which recurses through every descendant with no depth limit.
2. The tree has a cycle, and we recurse infinitely following the cycle
until we crash.
This commit converts all three functions from recursion to iterative DFS
using an explicit Vector stack, preventing the possibility of stack
overflow.
An iteration limit is added to avoid looping forever, and asserts are
added to detect cyles so we can try to debug and fix them (if that is
indeed what was causing this).
* LayoutTests/accessibility/aria-hidden-deep-dom-no-crash-expected.txt:
Added.
* LayoutTests/accessibility/aria-hidden-deep-dom-no-crash.html: Added.
* Source/WebCore/accessibility/AXCoreObject.h:
(WebCore::Accessibility::findUnignoredDescendant):
(WebCore::Accessibility::enumerateDescendantsIncludingIgnored):
(WebCore::Accessibility::enumerateUnignoredDescendants):
Canonical link: https://commits.webkit.org/311611@main
Canonical link: https://commits.webkit.org/305877.471@webkitglib/2.52
Commit: e4da6546450a23e93bc733749efa9af7c7dc5b01
https://github.com/WebKit/WebKit/commit/e4da6546450a23e93bc733749efa9af7c7dc5b01
Author: Chris Dumez <[email protected]>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
M Source/WebCore/contentextensions/ImmutableNFA.h
M Source/WebCore/contentextensions/ImmutableNFANodeBuilder.h
Log Message:
-----------
Cherry-pick 312425@main (07918cccab88).
https://bugs.webkit.org/show_bug.cgi?id=312298
Uninitialized memory write in
WebCore::ContentExtensions::SerializedNFA::serialize
https://bugs.webkit.org/show_bug.cgi?id=312298
rdar://175273937
Reviewed by Michael Catanzaro.
ImmutableRange<char> has 2 bytes of struct padding after its char fields.
When SerializedNFA serializes the transitions vector as raw bytes, valgrind
flags those uninitialized padding bytes passed to the write() syscall.
Add a default constructor that calls zeroBytes() to ensure padding is
always zeroed.
* Source/WebCore/contentextensions/ImmutableNFA.h:
(WebCore::ContentExtensions::ImmutableRange::ImmutableRange):
* Source/WebCore/contentextensions/ImmutableNFANodeBuilder.h:
(WebCore::ContentExtensions::ImmutableNFANodeBuilder::sinkTransitions):
Canonical link: https://commits.webkit.org/312425@main
Canonical link: https://commits.webkit.org/305877.472@webkitglib/2.52
Commit: bd4109270ef111055a019a637ad96311017b0449
https://github.com/WebKit/WebKit/commit/bd4109270ef111055a019a637ad96311017b0449
Author: Antti Koivisto <[email protected]>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
M Source/WebCore/style/MatchedDeclarationsCache.cpp
Log Message:
-----------
Cherry-pick 311862@main (ebcf88c1bc30).
https://bugs.webkit.org/show_bug.cgi?id=312236
Page memory grows unboundedly when animating @property-registered custom
properties consumed by calc() across many elements
https://bugs.webkit.org/show_bug.cgi?id=312236
rdar://171659746
Reviewed by Simon Fraser.
Some scenarios like animated custom properties may lead to unlimited cache
growth. While these should be fixed
with a better cache design it is also good idea to protect against this
with a hard maximum size.
* Source/WebCore/style/MatchedDeclarationsCache.cpp:
(WebCore::Style::MatchedDeclarationsCache::add):
Limit MDC size to 16k entries.
Canonical link: https://commits.webkit.org/311862@main
Canonical link: https://commits.webkit.org/305877.473@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/29ee6c3467ad...bd4109270ef1
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
