RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character [v3]

[Alexey Ivanov]

On Tue, 15 Jul 2025 03:58:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I'd expect to see 9 as the return value of getBeforeIndex for the index of 10. This would make the table symmetrical.
> 
> Why do you expect that? The spec states that the index should be "an index within the text." That index is also used in other methods, such as getCharacterBounds(), etc. If we fixed it only for text at the end, it would make the behavior even less symmetric, since for a negative value, the model will always throw an exception.

I think the specification for the index parameter — *“an index within the text”* — is vague, it's open to interpretation.

We should make it specific. For example, is 0 within the text? It's not within, it's right before.

The same goes for the index of 10 in my example above — it's right after the text.

> > According to the text model, index 10 is still valid, it's the index between the last character and the implied line break, so tf.getDocument().getText(10, 1) returns \n.
> 
> The last character is implementation detail, it is not part of the "users data" this is the reason why it is excluded from the Document.getLength().

Exactly! It's not part of the text itself, yet the index at `Document.getLength()` is a valid position.

I see no reason why accessible API would consider such a position invalid.

> > Ok, let's step away from the documentation and try to focus on the use case of this method. Method is supposed to expose navigation within the text component to the assistive technology devices and programs. One of such programs (not the only one) is a text narrator. These narrators are meant to be used on text components and they have special shortcuts to narrate the previous and next word or character compared to the current caret position.
> 
> Those narrators should not use the AccessibleText interface blindly. Instead, they should check the specification and decide which methods to call and when. The method in question cannot return the first or last word in some scenarios, so relying on it without understanding its limitations could lead to incorrect behavior.

In an ideal world… And again, *“an index within the text”* is a vague definition which one developer may interpret one way whereas another one may think it's okay. This bug, [JDK-8360070](https://bugs.openjdk.org/browse/JDK-8360070), is the proof for that.

As far as I can see, the implementation of `getIndexAtPoint` can return `Document.getLength()` as an index, which becomes inconsistent: the index is considered valid in some cases but it's invalid in other cases.

I think the proposed fix is backward compatible: it extends the range of valid indexes for a method call; reducing the range would be more problematic.

At the same time, I agree that all implementations of `AccessibleText` need updating to be consistent.

The specification for `AccessibleText` needs updating, too, to avoid any confusion: the valid range for the index parameter has to be explicitly defined such as `> 0 && < model.getLength()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3109915595