to_line_index loops indefinitely when a visual line starts with an empty text run

Start in accesskit_consumer/src/text.rs at TextPosition::to_line_index() and backward_to_line_start(), then trace the preceding_text_runs iterator and its line-boundary metadata. Reproduce with the supplied empty-run example and add regressions for leading empty runs, document-end positions, hard breaks, soft wraps, and empty lines. Done when the method terminates with the correct line number and the consumer and macOS adapter tests pass.

TextPosition::to_line_index() can repeatedly return to the same position when a visual line begins with an empty text run linked to a populated run. It never returns a line number. In the macOS adapter, this method serves accessibilityLineForIndex: and accessibilityInsertionPointLineNumber, so an affected request can block the calling thread.

Affected code and verification

Reproduced with published accesskit 0.25.1 / accesskit_consumer 0.39.1 and with AccessKit revision a39329d281a9381510496c17e81e87763edbb8bb. The failure is in platform-independent consumer code. Verification ran on macOS ARM64 with Rust 1.87.0; the reproduction uses no platform accessibility APIs or screen reader.

Minimal reproduction

One visual line contains two runs, "" and "a", with reciprocal next_on_line / previous_on_line links. Their character lengths are [] and [1], so the metadata matches the text. There is no hard line break or stored selection.

Cargo.toml:

[package]
name = "accesskit-empty-text-repros"
version = "0.1.0"
edition = "2024"
rust-version = "1.87"
publish = false

[dependencies]
accesskit = "=0.25.1"
accesskit_consumer = "=0.39.1"

src/main.rs:

use accesskit::{Node, NodeId, Role, TextDirection, TreeId, TreeInfo, TreeUpdate};
use accesskit_consumer::Tree;

fn main() {
    let mut field = Node::new(Role::MultilineTextInput);
    field.set_children([NodeId(1), NodeId(2)]);
    let mut first = Node::new(Role::TextRun);
    first.set_value("");
    first.set_character_lengths([]);
    first.set_text_direction(TextDirection::LeftToRight);
    first.set_next_on_line(NodeId(2));
    let mut last = Node::new(Role::TextRun);
    last.set_value("a");
    last.set_character_lengths([1]);
    last.set_text_direction(TextDirection::LeftToRight);
    last.set_previous_on_line(NodeId(1));
    let tree = Tree::new(
        TreeUpdate {
            nodes: vec![(NodeId(0), field), (NodeId(1), first), (NodeId(2), last)],
            tree: Some(TreeInfo::new(NodeId(0))),
            tree_id: TreeId::ROOT,
            focus: NodeId(0),
        },
        true,
    );
    let node = tree.state().root();
    let pos = node.text_position_from_global_utf16_index(0).unwrap();
    eprintln!("Computing line index; expected 0:");
    println!("{}", pos.to_line_index());
}

Run cargo run. It prints Computing line index; expected 0: and then does not terminate.

Expected behavior

The position is on the first visual line, so the method should promptly return 0.

Cause

to_line_index repeatedly calls backward_to_line_start() until is_document_start() is true. The UTF-16 lookup in this example returns character index 0 of the "a" run. backward_to_line_start then:

1. Biases backward to character index 0 of the preceding empty run.
2. Finds that empty run as the line start.
3. Biases forward from the empty run's end to character index 0 of the "a" run again.

The result has the same node and character index as the original position. It still has a preceding text run, so is_document_start() is false and the loop repeats. All character indices are in bounds; no tree update or stale selection is needed.

Proposed approach

Compute the zero-based line number by counting preceding visual-line boundaries with the finite preceding_text_runs iterator. Under the existing same-line metadata, each preceding run without a next_on_line link terminates a visual line. This avoids depending on normalized cursor movement making progress and preserves the public signature.

Add regressions for one or several leading empty runs on the first line and after a preceding line, including document-end positions. Preserve the existing hard-break and soft-wrap behavior, and cover empty lines and multiple linked runs per line.

I have a local candidate which fixes the reproduced loops and passes the existing default workspace and macOS adapter tests. The consumer implementation remains no_std. The change affects a shared method, whose current in-repository callers are in the macOS adapter; other-platform runtime testing and interactive accessibility testing have not been performed as part of this verification.

For comparison, Chromium's CreatePreviousLineStartPosition uses boundary traversal with explicit line-start/end predicates and movement options. The proposed AccessKit implementation instead counts its existing visual-line boundaries directly, avoiding a broader redesign of shared line navigation.