Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: c6bfb1759dd575c0178e46bd2f710f213dae2524
https://github.com/WebKit/WebKit/commit/c6bfb1759dd575c0178e46bd2f710f213dae2524
Author: Tyler Wilcock <[email protected]>
Date: 2025-02-11 (Tue, 11 Feb 2025)
Changed paths:
M Source/WebCore/accessibility/AXTextMarker.cpp
M Source/WebCore/accessibility/AXTextMarker.h
M Source/WebCore/accessibility/AXTextRun.cpp
M Source/WebCore/accessibility/AXTextRun.h
M Source/WebCore/accessibility/AccessibilityRenderObject.cpp
M Source/WebCore/accessibility/isolatedtree/AXIsolatedObject.cpp
M Source/WebCore/accessibility/isolatedtree/AXIsolatedObject.h
M Source/WebCore/accessibility/isolatedtree/mac/AXIsolatedObjectMac.mm
M Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperBase.mm
M Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm
Log Message:
-----------
AX: Serve NSAccessibilityBoundsForRangeParameterizedAttribute and
NSAccessibilityBoundsForTextMarkerRangeAttribute off the main-thread
https://bugs.webkit.org/show_bug.cgi?id=287369
rdar://106041510
Reviewed by Chris Fleizach.
This commits implements the ability to serve
NSAccessibilityBoundsForRangeParameterizedAttribute and
NSAccessibilityBoundsForTextMarkerRangeAttribute off the main-thread. We do
this by measuring the size of each character
in the text run and dividing the result by the number of characters. This means
we can compute a resonable frame for
any arbirtrary range of characters using this average character size.
This patch also implements conversion of rects to screen-relative space by
generalizing the existing logic for doing
so in AXIsolatedObject::screenRelativePosition(). Both bounds-for-range APIs
expect the returned rects to be in
screen-relative space.
In a future patch, we should implement a system that computes 100% accurate
character sizes on-demand for text ranges
that ATs are actually interacting with via these APIs. So if an AT requests
NSAccessibilityBoundsForTextMarkerRangeAttribute
for one range, we serve an estimate, and then compute the true per-character
widths for that text and also nearby text
under the assumption that an AT is likely going to move there next. An example
usecase might be line-by-line navigation,
where if one of these APIs is requested for one line, it's likely the user will
continue moving down to the next lines.
This commit leaves other problems unresolved, too — specifically:
- AXTextRuns::rect() likely does not do the right thing for vertical writing
modes.
- We probably need to special-case certain types of text-run-producing
objects, like those from br elements.
We'll need to address these in later commits.
* Source/WebCore/accessibility/AXTextMarker.cpp:
(WebCore::viewportRelativeFrameFromRuns):
(WebCore::AXTextMarkerRange::viewportRelativeFrame const):
* Source/WebCore/accessibility/AXTextMarker.h:
* Source/WebCore/accessibility/AXTextRun.cpp:
(WebCore::AXTextRuns::rect const):
* Source/WebCore/accessibility/AXTextRun.h:
(WebCore::AXTextRuns::AXTextRuns):
* Source/WebCore/accessibility/AccessibilityRenderObject.cpp:
(WebCore::AccessibilityRenderObject::textRuns):
* Source/WebCore/accessibility/isolatedtree/AXIsolatedObject.h:
* Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]):
Canonical link: https://commits.webkit.org/290242@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
