[webkit-changes] [WebKit/WebKit] 9ac2c0: AX: AccessibilityObject::visibleCharacterRange() r...

[Tyler Wilcock]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9ac2c0188b7d0974774a40da80a628b1bd82b89e
      https://github.com/WebKit/WebKit/commit/9ac2c0188b7d0974774a40da80a628b1bd82b89e
  Author: Tyler Wilcock <tyler_w at apple.com>
  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