Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#837 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
50/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
accessibility, backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
1.5k
Fork
127
Merge trung bình
16 giờ 44 phút
Pull request đã merge (30 ngày)
12

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của AccessKit/accesskit

Tất cả issue của AccessKit/accesskit

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.