Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: cb96444da8f4ed8ba4e8f4139e582f5226f6ef01
https://github.com/WebKit/WebKit/commit/cb96444da8f4ed8ba4e8f4139e582f5226f6ef01
Author: Fujii Hironori <[email protected]>
Date: 2026-05-11 (Mon, 11 May 2026)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/graphics/skia/ComplexTextControllerSkia.cpp
M Source/WebCore/platform/graphics/skia/FontCascadeSkia.cpp
Log Message:
-----------
Cherry-pick 312992@main (d86ea95fa305).
https://bugs.webkit.org/show_bug.cgi?id=310352
[Skia] Fix missing glyph before ZWJ/ZWNJ if no font is found for the cluster
https://bugs.webkit.org/show_bug.cgi?id=310352
Reviewed by Carlos Garcia Campos.
For example, "X‍" showed a .notdef glyph if no font was found for the
cluster because FontCascade::fontForCombiningCharacterSequence() returned
nullptr
for it.
Changed FontCascade::fontForCombiningCharacterSequence() to return a font
for
the base character if no font is found for the cluster.
After the above change, the layout test
imported/w3c/web-platform-tests/css/css-text/line-break/line-break-anywhere-overrides-uax-behavior-016.html
failed. HarfBuzz shaped " ‍" as two space glyphs, and the second space
glyph had zero width, and the cluster of both glyphs was associated with the
first space character. Then,
ComplexTextController::adjustGlyphsAndAdvances()
treated the second space glyph with zero width as a space character. To work
around this problem, we used HB_BUFFER_CLUSTER_LEVEL_CHARACTERS to separate
the
cluster. Thus, the cluster for the second space glyph is now ZWJ.
Tests: fast/text/thai-joiner.html
* LayoutTests/platform/glib/TestExpectations:
* Source/WebCore/platform/graphics/skia/ComplexTextControllerSkia.cpp:
(WebCore::ComplexTextController::collectComplexTextRunsForCharacters):
* Source/WebCore/platform/graphics/skia/FontCascadeSkia.cpp:
(WebCore::FontCascade::fontForCombiningCharacterSequence const):
Canonical link: https://commits.webkit.org/312992@main
Canonical link: https://commits.webkit.org/305877.485@webkitglib/2.52
Commit: 024db53352818c8e3958b536472f23daaf4b1af1
https://github.com/WebKit/WebKit/commit/024db53352818c8e3958b536472f23daaf4b1af1
Author: Zak Ridouh <[email protected]>
Date: 2026-05-11 (Mon, 11 May 2026)
Changed paths:
A PerformanceTests/Layout/deep-nesting-overflow-siblings.html
M Source/WebCore/style/StyleTreeResolver.cpp
Log Message:
-----------
Cherry-pick 312751@main (69a399de80ab).
https://bugs.webkit.org/show_bug.cgi?id=314139
REGRESSION (297241@main): Overflow siblings at parser's max DOM tree depth
get fully rendered, causing slow layout
https://bugs.webkit.org/show_bug.cgi?id=314139
rdar://172219636
Reviewed by Sammy Gill and Alan Baradlay.
When the parser's DOM depth cap is reached,
HTMLConstructionSite::attachLater
attaches further elements as siblings at the boundary depth (see
297241@main).
The render tree's depth check skipped elements above the cap but not at it,
so the overflow run was fully styled and laid out — causing ~15s render
times
on content with thousands of overflow siblings (e.g. mail with embedded
crash
logs containing unmatched <unavailable> tags).
At the maximum render tree depth, skip elements that have a previous element
sibling. The single legitimate deepest element keeps its renderer; the
overflow siblings get none.
* PerformanceTests/Layout/deep-nesting-overflow-siblings.html: Added.
* Source/WebCore/style/StyleTreeResolver.cpp:
(WebCore::Style::TreeResolver::resolveComposedTree):
Canonical link: https://commits.webkit.org/312751@main
Canonical link: https://commits.webkit.org/305877.486@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/02dec333499a...024db5335281
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
