On Tue, 15 Jul 2025 03:58:55 GMT, Sergey Bylokhov <s...@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
