Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 9a59ea98b0a6cb5746f0898a18118dba56b57c1a
https://github.com/WebKit/WebKit/commit/9a59ea98b0a6cb5746f0898a18118dba56b57c1a
Author: Tyler Wilcock <[email protected]>
Date: 2025-06-02 (Mon, 02 Jun 2025)
Changed paths:
A
LayoutTests/accessibility/mac/bounds-for-range-multibyte-glyphs-expected.txt
A LayoutTests/accessibility/mac/bounds-for-range-multibyte-glyphs.html
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/accessibility/AXTextMarker.cpp
M Source/WebCore/accessibility/AXTextMarker.h
M Source/WebCore/accessibility/AXTextRun.cpp
M Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm
M Source/WebCore/platform/graphics/ComplexTextController.cpp
Log Message:
-----------
AX: Crash when navigating character-by-character via VoiceOver in text with
multi-byte glyphs (e.g. emojis)
https://bugs.webkit.org/show_bug.cgi?id=293753
rdar://152255108
Reviewed by Vitor Roriz.
In AccessibilityRenderObject::textRuns, when we build text runs for use off the
main-thread, part of that process
is measuring and storing character widths. It's important that the character
widths we cache match the length of the
string. This matters particularly when considering multi-byte glyphs like
certain emojis, which can expand the length
of the string multiple times (e.g. some emojis are 10 characters long!) but
only take up one position in the GlyphBuffer.
To handle this, we padded our cached character widths with zeros based on the
result of GlyphBuffer::uncheckedStringOffsetAt,
which should tell us how big the gaps created by multi-byte glyphs are.
Unfortunately, ComplexTextController did not
compute this value correctly when building the glyph buffer. It only added the
glyph index as the string offset, and
the glyph index is only relevant in the context of a single ComplexTextRun, not
the overall string. This is easily
fixed by also adding the ComplexTextRun::stringLocation to get the real string
offset for the glyph. This fixes the
crash by ensuring we pad our character widths vector as intended, thus avoiding
an out-of-bounds access assert.
This commit also fixes an issue where bounding boxes for text containing
multi-byte glyphs became completely wrong.
This happened because when we converted an NSRange (a location, and length
based on the whole length of the string,
including sub-characters of a multi-byte glyph), we walked over the multi-byte
glyphs as one "location", meaning
we would generate a text marker with the wrong offset.
Fix this by passing a new parameter to AXTextMarker::findMarker that forces
walks through sub-characters of multi-byte
glyphs, rather than walking over them atomically. We'll need to use this in any
place an accessibility API takes an
NSRange.
* LayoutTests/accessibility/mac/bounds-for-range-multibyte-glyphs-expected.txt:
Added.
* LayoutTests/accessibility/mac/bounds-for-range-multibyte-glyphs.html: Added.
* LayoutTests/platform/mac-wk1/TestExpectations:
* Source/WebCore/accessibility/AXTextMarker.cpp:
(WebCore::AXTextMarker::nextMarkerFromOffset const):
(WebCore::AXTextMarker::findMarker const):
* Source/WebCore/accessibility/AXTextMarker.h:
* Source/WebCore/accessibility/AXTextRun.cpp:
(WebCore::AXTextRuns::localRect const):
* Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(computeTextBoundsForRange):
* Source/WebCore/platform/graphics/ComplexTextController.cpp:
(WebCore::ComplexTextController::enclosingGlyphBoundsForTextRun):
Canonical link: https://commits.webkit.org/295703@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
