Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: 92d4a33fd58a2ba5cf17eaa2ac5d979589989108
https://github.com/WebKit/WebKit/commit/92d4a33fd58a2ba5cf17eaa2ac5d979589989108
Author: Geoffrey Garen <[email protected]>
Date: 2026-08-10 (Mon, 10 Aug 2026)
Changed paths:
M Source/WTF/WTF.xcodeproj/project.pbxproj
M Source/WTF/wtf/CMakeLists.txt
M Source/WTF/wtf/InlineWeakPtr.h
M Source/WTF/wtf/InlineWeakRef.h
A Source/WTF/wtf/Nonallocatable.h
M Source/WTF/wtf/RefCountedWithInlineWeakPtr.h
M Source/WTF/wtf/UniquelyOwned.h
M Source/WTF/wtf/UniquelyOwnedPtr.h
M Source/WebCore/SaferCPPExpectations/UncheckedCallArgsCheckerExpectations
M Source/WebCore/SaferCPPExpectations/UncountedCallArgsCheckerExpectations
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Tools/TestWebKitAPI/CMakeLists.txt
M Tools/TestWebKitAPI/Tests/WTF/CheckedPtr.cpp
M Tools/TestWebKitAPI/Tests/WTF/HashMap.cpp
M Tools/TestWebKitAPI/Tests/WTF/HashSet.cpp
M Tools/TestWebKitAPI/Tests/WTF/ListHashSet.cpp
A Tools/TestWebKitAPI/Tests/WTF/RefCountedWithInlineWeakPtr.cpp
Log Message:
-----------
Cherry-pick 318846@main (f880bc57ad50).
https://bugs.webkit.org/show_bug.cgi?id=321243
Unreviewed backport.
RefCountedWithInlineWeakPtr is undef in GCC 15
https://bugs.webkit.org/show_bug.cgi?id=321243
rdar://184290928
Reviewed by Ryosuke Niwa.
This patch moves the refcount bits in RefCountedWithInlineWeakPtr<T> into a
separately declared type that is adjacent to T, instead of a base class of
T.
Technically, it is undef to read bits out of T after ~T(), and GCC 15 is
aggressive about this. Separating the types works around this restriction.
The allocation and data layout should remain the exact same in practice.
Canonical link: https://commits.webkit.org/318846@main
Canonical link: https://commits.webkit.org/317695.79@webkitglib/2.54
Commit: 57bc60933f81f07a1555885b47de87f6687c5f25
https://github.com/WebKit/WebKit/commit/57bc60933f81f07a1555885b47de87f6687c5f25
Author: Fujii Hironori <[email protected]>
Date: 2026-08-10 (Mon, 10 Aug 2026)
Changed paths:
M
Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedBackingStoreTile.cpp
M
Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedBackingStoreTile.h
Log Message:
-----------
Cherry-pick 318446@main (6580afcaf2cd).
https://bugs.webkit.org/show_bug.cgi?id=320881
[Coordinated Graphics] Unnecessary texture allocation in the fast path of
CoordinatedBackingStoreTile::processPendingUpdates
https://bugs.webkit.org/show_bug.cgi?id=320881
Reviewed by Carlos Garcia Campos.
CoordinatedBackingStoreTile::processPendingUpdates() has the fast path for
the
case the whole tile content is changed. In this case, a texture was
allocated,
then it was just freed in the case m_texture is null.
SkiaBackingStore also has this fast path, but it doesn't have this problem.
Follow the style of SkiaBackingStore.
*
Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedBackingStoreTile.cpp:
(WebCore::CoordinatedBackingStoreTile::ensureTexture): Added.
(WebCore::CoordinatedBackingStoreTile::processPendingUpdates):
*
Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedBackingStoreTile.h:
Canonical link: https://commits.webkit.org/318446@main
Canonical link: https://commits.webkit.org/317695.80@webkitglib/2.54
Commit: f21db296a92251c46840c08bce46602b23d991c1
https://github.com/WebKit/WebKit/commit/f21db296a92251c46840c08bce46602b23d991c1
Author: Sean Patterson <[email protected]>
Date: 2026-08-10 (Mon, 10 Aug 2026)
Changed paths:
A
LayoutTests/fast/html/details-display-contents-scrollable-content-crash-expected.txt
A
LayoutTests/fast/html/details-display-contents-scrollable-content-crash.html
M Source/WebCore/rendering/RenderLayerScrollableArea.cpp
Log Message:
-----------
Cherry-pick 318661@main (9510cbdd8452).
https://bugs.webkit.org/show_bug.cgi?id=320447
Null-deref crash in RenderElement::resolvePseudoElementStyle() when a
<details> element has `display: contents` and its ::details-content establishes
a scrollable area
https://bugs.webkit.org/show_bug.cgi?id=320447
rdar://183445758
Reviewed by Simon Fraser.
rendererForScrollbar() maps a renderer inside a user agent shadow root to
its
shadow host's renderer, so that scrollbar pseudo element styles are resolved
against the host. It returned the host's renderer unconditionally, but a
host
with `display: contents` has no renderer. Its user agent shadow content can
still establish a scrollable area, so all three callers dereferenced null.
A <details> is exactly that case: its ::details-content is a slot in the
user
agent shadow root, so giving the <details> `display: contents` and the
::details-content non-visible overflow crashed the WebContent process while
resolving the scroll corner style during render tree construction. This is
the
standard way to build an animated disclosure widget whose summary
participates
in a parent grid, so it is reachable from ordinary content.
Null check the host's renderer and fall back to the renderer establishing
the
scrollable area, which is the pre-existing behavior for content outside a
user
agent shadow root. Only the null case changes behavior.
* Source/WebCore/rendering/RenderLayerScrollableArea.cpp:
(WebCore::rendererForScrollbar): The host is not guaranteed to have a
renderer.
It has none when it is `display: contents`, even though its user agent
shadow
content may still establish a scrollable area. Fall back to the renderer
establishing the scrollable area rather than returning null, since the
callers
all dereference the result to resolve the scrollbar pseudo element styles
against it: updateScrollCornerStyle(), updateResizerStyle() and
createScrollbar().
*
LayoutTests/fast/html/details-display-contents-scrollable-content-crash.html:
Added.
*
LayoutTests/fast/html/details-display-contents-scrollable-content-crash-expected.txt:
Added.
Covers all three call sites: a scroll corner, a resizer (`resize: both`) and
scrollbar creation (`overflow: scroll` with overflowing content). Crashes
without the fix, passes with it.
Canonical link: https://commits.webkit.org/318661@main
Canonical link: https://commits.webkit.org/317695.81@webkitglib/2.54
Commit: 7141cc1387fe0291714143ad6dd12ca32563d1b7
https://github.com/WebKit/WebKit/commit/7141cc1387fe0291714143ad6dd12ca32563d1b7
Author: Kristian Monsen <[email protected]>
Date: 2026-08-10 (Mon, 10 Aug 2026)
Changed paths:
A LayoutTests/fast/text/text-spacing-trim-null-font-crash-expected.txt
A LayoutTests/fast/text/text-spacing-trim-null-font-crash.html
M Source/WebCore/platform/graphics/WidthIterator.cpp
Log Message:
-----------
Cherry-pick 318619@main (53bedf3f8f4d).
https://bugs.webkit.org/show_bug.cgi?id=321023
Crash in WidthIterator::applyTextSpacingTrimIfNeeded when a character has
no glyph in any font
https://bugs.webkit.org/show_bug.cgi?id=321023
rdar://183317081
Reviewed by Vitor Roriz.
glyphDataForCharacter() can legitimately return a GlyphData with a null
font (a SingleThreadWeakPtr<const Font>) whenever no font — including every
fallback — has a glyph for the
character, which happens for code points like U+001F that no installed font
maps. applyTextSpacingTrimIfNeeded() didn't account for that case: it
unconditionally did
*protect(glyphData.font) to pass the font by reference into
getHalfWidthFontIfNeeded(), dereferencing a null RefPtr and crashing.
The fix adds a !glyphData.font check alongside the existing isSpaceAll()
early return, so the function bails out before dereferencing when there's no
font to consult. This mirrors
how the equivalent code in ComplexTextController.cpp already guards the
same lookup with nextFont && before touching it — this path is now consistent
with that sibling
implementation. Since a glyph-less character has no font whose text-spacing
metrics could apply anyway, skipping the trim logic in that case is correct
behavior, not just a crash
guard.
Test: fast/text/text-spacing-trim-null-font-crash.html
* LayoutTests/fast/text/text-spacing-trim-null-font-crash-expected.txt:
Added.
* LayoutTests/fast/text/text-spacing-trim-null-font-crash.html: Added.
* Source/WebCore/platform/graphics/WidthIterator.cpp:
(WebCore::applyTextSpacingTrimIfNeeded):
Canonical link: https://commits.webkit.org/318619@main
Canonical link: https://commits.webkit.org/317695.82@webkitglib/2.54
Commit: 058cf02cf86d97ce6bc750c22d05ff8643b7ead5
https://github.com/WebKit/WebKit/commit/058cf02cf86d97ce6bc750c22d05ff8643b7ead5
Author: Chris Dumez <[email protected]>
Date: 2026-08-10 (Mon, 10 Aug 2026)
Changed paths:
A
LayoutTests/fast/css/webkit-border-image-width-length-serialization-expected.txt
A LayoutTests/fast/css/webkit-border-image-width-length-serialization.html
M Source/WebCore/css/parser/CSSPropertyParserConsumer+Background.cpp
Log Message:
-----------
Cherry-pick 318214@main (3801ac23e164).
https://bugs.webkit.org/show_bug.cgi?id=320545
REGRESSION(313588@main): -webkit-border-image width flag is lost when a
length edge precedes a non-length edge
https://bugs.webkit.org/show_bug.cgi?id=320545
Reviewed by Sam Weinig and Darin Adler.
The -webkit-border-image legacy behavior treats a border-image-width whose
value
contains a fixed <length> as also overriding the element's border widths.
The
parser records this in the "hasLength" flag, which must be true if ANY of
the
up-to-four width edges is a length.
313588@main refactored consumeUnresolvedBorderImageWidth() and, in the
process,
silently changed how "hasLength" is accumulated:
```
Before: if (numericValue->isLength())
hasLength = true; // monotonic latch
After: hasLength = WTF::switchOn(...) // last-write-wins overwrite
```
With the overwrite, "hasLength" ends up reflecting only the last
length-percentage edge instead of whether any edge is a length. For a width
such
as `10px 5%`, the length edge (10px) sets it true, then the percentage edge
(5%)
overwrites it back to false.
This corrupts the stored legacyWebkitBorderImage flag, which two independent
consumers (ShorthandSerializer and the style extractor) recompute as
anyOf(isLength) and compare against. On mismatch they bail out, so
`-webkit-border-image: url(...) 10 / 10px 5%` fails to serialize (returns
the
empty string) via getComputedStyle / cssText, and the legacy border-width
override is dropped at paint time. The result is order-dependent: `5% 10px`
round-trips but `10px 5%` does not.
Restore the original monotonic-latch semantics by OR-accumulating the flag
across edges.
Test: fast/css/webkit-border-image-width-length-serialization.html
* Source/WebCore/css/parser/CSSPropertyParserConsumer+Background.cpp:
(WebCore::CSSPropertyParserHelpers::consumeUnresolvedBorderImageWidth):
*
LayoutTests/fast/css/webkit-border-image-width-length-serialization-expected.txt:
Added.
* LayoutTests/fast/css/webkit-border-image-width-length-serialization.html:
Added.
Canonical link: https://commits.webkit.org/318214@main
Canonical link: https://commits.webkit.org/317695.83@webkitglib/2.54
Commit: 724182cc2439d9cd7ec44057e5f87aee6ef003fb
https://github.com/WebKit/WebKit/commit/724182cc2439d9cd7ec44057e5f87aee6ef003fb
Author: Chris Dumez <[email protected]>
Date: 2026-08-10 (Mon, 10 Aug 2026)
Changed paths:
M Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp
Log Message:
-----------
Cherry-pick 318204@main (5d91250a8529).
https://bugs.webkit.org/show_bug.cgi?id=320408
CacheStorage size accounting can underflow and persist a corrupt size
https://bugs.webkit.org/show_bug.cgi?id=320408
Reviewed by Youenn Fablet.
CacheStorageManager::sizeDecreased() subtracted the given amount from m_size
without checking that it did not exceed the current value. m_size is a
uint64_t,
so if the amount ever exceeds the tracked size the subtraction wraps to a
value
near UINT64_MAX, which is then written to the cache's size file and used for
quota accounting, effectively corrupting quota reporting for the origin
until
the size is re-initialized.
The tracked size is normally kept consistent (increments and decrements are
balanced in putRecordsInStore), but removeRecords() and removeAllRecords()
call
sizeDecreased() directly, outside the space-request/initialization path, so
the
in-memory accounting and the asynchronously-measured cache size can in
theory
drift and the decrement can exceed m_size.
Clamp the subtraction at zero, matching the saturating arithmetic used
elsewhere
in this code.
* Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp:
(WebKit::CacheStorageManager::sizeDecreased):
Canonical link: https://commits.webkit.org/318204@main
Canonical link: https://commits.webkit.org/317695.84@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/b7adb8705135...724182cc2439
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
