Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 9ac2c0188b7d0974774a40da80a628b1bd82b89e
https://github.com/WebKit/WebKit/commit/9ac2c0188b7d0974774a40da80a628b1bd82b89e
Author: Tyler Wilcock <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
A LayoutTests/accessibility/visible-character-range-vertical-rl-expected.txt
A LayoutTests/accessibility/visible-character-range-vertical-rl.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/accessibility/AccessibilityObject.cpp
M Source/WebCore/accessibility/AccessibilityObject.h
Log Message:
-----------
AX: AccessibilityObject::visibleCharacterRange() returns the wrong result for
vertical writing mode text that is only partially visible
https://bugs.webkit.org/show_bug.cgi?id=283330
rdar://140158374
Reviewed by Chris Fleizach.
AccessibilityObject::visibleCharacterRange() is implemented by shrinking the
start and end of the element's rect
line-by-line until it fits within the viewport. The problem was that the logic
for determining whether to start or
continue shrinking lines was based on checking rect.location() for shrinking
the start of the text, or rect.location() + rect.size()
for the shrinking the end. This is wrong for "flipped" writing-modes (e.g.
vertical-rl), whose `x` represents the end
of the text, not the start. This meant we would shrink the end lines when we
actually should've been shrinking the start,
and vice versa (hence this problem being specific to "flipped" writing modes).
With this commit, this logic now properly checks for and handles flipped
writing modes. A test is added to prove we
behave correctly.
This commit also critically removes
AccessibilityObject::m_cachedVisibleCharacterRange and
AccessibilityObject::m_cachedVisibleCharacterRangeInputs.
These caches were added to make repeated calls for the same
visibleCharacterRange fast, as Books seemed to be doing this
in the past. However, it doesn't seem to be doing this anymore. This cache was
not a great idea in the first place (I added it).
It adds 120 bytes of size to every single AccessibilityObject, even if nothing
has or will request visibleCharacterRange on it.
Removing it saves a substantial amount of memory — 68.1mb on
http://html.spec.whatwg.org (567769 objects times 120 bytes).
* LayoutTests/accessibility/visible-character-range-vertical-rl-expected.txt:
Added.
* LayoutTests/accessibility/visible-character-range-vertical-rl.html: Added.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/ios/TestExpectations:
* LayoutTests/platform/mac-wk1/TestExpectations:
* Source/WebCore/accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::lastBoundaryPointContainedInRect const):
(WebCore::textStartPoint):
(WebCore::textEndPoint):
(WebCore::AccessibilityObject::boundaryPointsContainedInRect const):
(WebCore::AccessibilityObject::visibleCharacterRange const):
(WebCore::AccessibilityObject::visibleCharacterRangeInternal const):
* Source/WebCore/accessibility/AccessibilityObject.h:
(WebCore::AccessibilityObject::lastBoundaryPointContainedInRect const):
Canonical link: https://commits.webkit.org/286780@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
