I think we would all feel a lot safer merging this if we get system tests for libre Office and notepad++. I'm not sure how feasible it is to install them on GitHub runners, but I think it's worth investigating as we've had this be a constant, testable problem.

Agreed there. Problem with LibreOffice is that it has a first start experience with tips at startup. I think they'll be getting in the way during tests, unless there's a workaround for that. May be @michaelweghorn can chime in here?

Problem with LibreOffice is that it has a first start experience with tips at startup. I think they'll be getting in the way during tests, unless there's a workaround for that. May be @michaelweghorn can chime in here?

Tips (and other things like infobars, first start wizard,...) can be disabled via a LibreOffice option/setting. https://wiki.documentfoundation.org/Deployment_and_Migration#Post_deployment_configuration describes some ways those can be deployed/set before starting LibreOffice.
I can look into that in more detail once it becomes relevant - please just let me know.

@LeonarddeR , I like this a lot.
In LibreOffice Writer, when we are in the last line, trying to scroll forward the cursor is not moved to the end, and this is not consistent with other applications. I didn't know this, but a fellow of a spanish mailing list has reported that some braille displays don't have routing keys, so sometimes maybe desirable to move the cursor to the end of the document, if possible. Can you add another parameter to return True if the object is the last one, or something like that, or should this be done in braille.py?

@nvdaes Does the issue you're describing also apply to NVDA 2025.3 and older? In that case, we definitely need to handle that separately, though it is slightly related.

@LeonarddeR wrote:

Does the issue you're describing also apply to NVDA 2025.3 and older?

I tested this with NVDA 2025.3.1 and the issue, i.e., cursor is not moved to the end of the document from the last braille window when scrolling forward, is happening, so the described issue is not a regression. I was wondering if your new function should cover this case, to allow move the cursor to the end when no more text or objects are available.

I was wondering if your new function should cover this case, to allow move the cursor to the end when no more text or objects are available.

I might be able to do this.

Leonard wrote:

I might be able to do this.

Great. If this should be done in a different PR, I don't mind to implement this using your new function, or if you can do it here, great too.

@nvdaes I think the last commit should fix this and make this consistent to other textInfo impls.

Leonard wrote:

I think the last commit should fix this and make this consistent to other textInfo impls.

The behavior is not consistent with other programs, since the cursor moves to the last character of the document, not to the end, i.e., after the last character.
Locally, I fixed this like that, using your function in the compoundDocuments file:

def allowMoveToUnitOffsetPastEnd(self, unit: str) -> bool:
return unit in (textInfos.UNIT_CHARACTER, textInfos.UNIT_WORD) or self.obj.flowsTo is None

This produces a consistent behavior in LibreOffice Writer, though perhaps another solution is better.

@nvdaes wrote:

Locally, I fixed this like that, using your function in the compoundDocuments file:

def allowMoveToUnitOffsetPastEnd(self, unit: str) -> bool:
return unit in (textInfos.UNIT_CHARACTER, textInfos.UNIT_WORD) or self.obj.flowsTo is None

This produces a consistent behavior in LibreOffice Writer, though perhaps another solution is better.

No no, this solution is actually very elegant and perfect, thank you very much for proposing it. I added it just now.

Thanks @LeonarddeR - this fix looks good to me but would also like a review from @SaschaCowley .
Additionally, have you had a chance to investigate system tests?

Apart from that I'm not very comfortabele with system test writing yet, I think it is a problem that a runner might need to install LibreOffice before it can be used. A LibreOffice installation takes a significant amount of time. May be we can use the version in the portable apps format

A LibreOffice installation takes a significant amount of time. May be we can use the version in the portable apps format

Yeah caching a portable format I think would be ideal