Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 61bc74179682cf9d197ea60c474513550869b52a
https://github.com/WebKit/WebKit/commit/61bc74179682cf9d197ea60c474513550869b52a
Author: Tyler Wilcock <[email protected]>
Date: 2026-09-01 (Tue, 01 Sep 2026)
Changed paths:
A
LayoutTests/accessibility/isolated-tree/mac/line-ranges-at-br-not-duplicated-expected.txt
A
LayoutTests/accessibility/isolated-tree/mac/line-ranges-at-br-not-duplicated.html
A
LayoutTests/accessibility/mac/line-ranges-at-br-not-duplicated-expected.txt
A LayoutTests/accessibility/mac/line-ranges-at-br-not-duplicated.html
M Source/WebCore/accessibility/AXTextMarker.cpp
Log Message:
-----------
AX: In isolated tree mode, AXStringForTextMarkerRange reports an unexpected
extra newline for a br element
https://bugs.webkit.org/show_bug.cgi?id=322443
rdar://185725696
Reviewed by Dominic Mazzoni.
AccessibilityRenderObject::textRuns gives a RenderLineBreak a "\n" run whose
lineID is
(containingBlock, box->lineIndex()). This is the same lineID as the text before
it, because a br
sits on the line it breaks. The position just past that newline is therefore
another end of
the line the br ended, not the end of the line after it.
The line walk backing AXTextMarkerRangeForLine advanced with nextLineEnd and
stopped only
once the marker didn't move at all, so it reported such a line twice: once
without its
trailing break, then again with it. For <p>Alpha<br>Bravo</p> that exposed
three lines —
"Alpha", "Alpha\n", "Bravo" — where the live tree exposes two, shifting every
later line
index by one.
Landing past the <br>'s newline is nextLineEnd's correct, live-matching
behavior, specified
by accessibility/mac/line-boundary-at-br.html, so this fixes the line
enumeration built on
top of it rather than nextLineEnd itself. nextLineRange now keeps advancing
while the line
end it finds still carries the line ID it started from.
AXLineForTextMarker counts lines with its own walk and had the same off-by-one,
which would
have left the two attributes disagreeing about a <br>. Its fast path (same
containing block,
subtract line indices) was already correct, so only a marker in a later block
was affected.
It now counts a line only when the line ID changes.
*
LayoutTests/accessibility/isolated-tree/mac/line-ranges-at-br-not-duplicated-expected.txt:
Added.
*
LayoutTests/accessibility/isolated-tree/mac/line-ranges-at-br-not-duplicated.html:
Added.
* LayoutTests/accessibility/mac/line-ranges-at-br-not-duplicated-expected.txt:
Added.
* LayoutTests/accessibility/mac/line-ranges-at-br-not-duplicated.html: Added.
* Source/WebCore/accessibility/AXTextMarker.cpp:
(WebCore::AXTextMarker::lineIndex const):
(WebCore::nextLineRange):
Canonical link: https://commits.webkit.org/320305@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
