to_line_index loops indefinitely when a visual line starts with an empty text run
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 50/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- rust
- Ambito
- accessibility, backend
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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:
- Biases backward to character index 0 of the preceding empty run.
- Finds that empty run as the line start.
- 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.
- Lingua principale
- Rust
- Stelle
- 1.5k
- Fork
- 127
- Merge medio
- 16h 44m
- PR unite (30g)
- 12
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di AccessKit/accesskit
-
Document sub-treesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Document `Role::ColorWell`Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 1-2 giorni Idoneità per principianti 32/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di AccessKit/accesskit
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
haowjy/mars-agents#228 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
redlib-org/redlib#604 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
dividebysandwich/rust-dos#240 ·
I maintainer di solito rispondono entro 1 giorno
-
A-UI C-Bug S-Needs-Triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
bevyengine/bevy#26330 ·
I maintainer di solito rispondono entro 2 giorni