macOS character-range lookup panics at a run boundary before empty text runs

Start with adapters/macos/src/util.rs and the to_ns_range_for_character helper, then read the cited text-position methods in accesskit_consumer/src/text.rs. Reproduce the panic with the supplied tree and position, and add a native unit test for the helper covering empty runs at document boundaries. Done means the helper returns a zero-length range at the document UTF-16 length without panicking; the issue also describes additional empty-run and Unicode cases to cover.

accesskit_macos::to_ns_range_for_character can advance a valid position to character index 1 of an empty text run, then panic while converting that position to a UTF-16 index. The helper is used by accessibilityRangeForPosition:; a panic in that accessibility callback can terminate the application.

Affected code and verification

Reproduced with published accesskit 0.25.1 / accesskit_consumer 0.39.1, and with the actual macOS helper in accesskit_macos 0.27.1 at AccessKit revision a39329d281a9381510496c17e81e87763edbb8bb. Native tests ran on macOS ARM64 with Rust 1.87.0. No live screen-reader session is needed for these reproductions.

Minimal reproduction

The tree contains "a\n" followed by an empty run for the final blank line. A point just to the right of the first run produces its end position, at character index 2. The run's two characters each occupy one UTF-8 byte; the empty run has no characters. No stored text selection is involved.

The helper is private. This standalone program uses public consumer APIs to obtain the position and repeats the helper's existing range calculation, returning UTF-16 endpoints instead of an NSRange.

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, Point, Rect, 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)]);
    field.set_bounds(Rect::new(0.0, 0.0, 100.0, 40.0));
    let mut first = Node::new(Role::TextRun);
    first.set_value("a\n");
    first.set_bounds(Rect::new(0.0, 0.0, 10.0, 20.0));
    first.set_character_lengths([1, 1]);
    first.set_text_direction(TextDirection::LeftToRight);
    let mut last = Node::new(Role::TextRun);
    last.set_value("");
    last.set_bounds(Rect::new(0.0, 20.0, 0.0, 40.0));
    last.set_character_lengths([]);
    last.set_text_direction(TextDirection::LeftToRight);
    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();
    // A point just past the first run returns that run's end position.
    let pos = node.text_position_at_point(Point::new(11.0, 10.0));

    // This is the current macOS to_ns_range_for_character algorithm, returning
    // the UTF-16 endpoints instead of constructing an NSRange.
    let mut range = pos.to_degenerate_range();
    if !pos.is_document_end() {
        range.set_end(pos.forward_to_character_end());
    }
    println!(
        "{}..{}",
        range.start().to_global_utf16_index(),
        range.end().to_global_utf16_index()
    );
}

Run cargo run. The process exits with code 101 in the default development profile:

range end index 1 out of range for slice of length 0

For a native regression, use the same tree and position in a unit test inside adapters/macos/src/util.rs, and call to_ns_range_for_character(&pos) directly. That call also panics on the revision above.

Expected behavior

At UTF-16 offset 2, there is no following character. The helper should return NSRange { location: 2, length: 0 } without creating an out-of-bounds text position.

Cause

to_ns_range_for_character checks is_document_end() on the original position. Although its global offset is at the end of the text, it is anchored to the populated run, and another run follows, so the check returns false.

forward_to_character_end biases into the next run and unconditionally increments the character index from 0 to 1. For an empty run, only index 0 is valid. to_global_utf16_index then slices character_lengths[..1], causing the panic. The character movement itself produces the invalid index.

Proposed approach

Normalize the position before the end check and range expansion: move from a run end to the next run's start, continuing past empty runs until a character is available or the last run is reached. At the last empty run, return a zero-length range at the document's UTF-16 length.

Keep this change local to the macOS helper. Add regressions for one or several trailing and leading empty runs, entirely empty documents, empty runs between populated runs, and UTF-16 lengths of supplementary and multi-code-point characters. Normalization must advance through the runs on each iteration so that it terminates.

I have a local patch which fixes the reproduced helper failures and passes the existing default workspace and macOS adapter tests.

For comparison, Chromium's CreateNextCharacterPosition first normalizes with AsLeafTextPositionBeforeCharacter, handles a null result, then advances within a bounded text offset.