Fix OffsetTextInfo.collapse() and OffsetTextInfo.move()#18348
Conversation
See test results for failed build of commit e48645facd |
|
@nvdaes, could you test that this doesn't break #17430? |
|
Thanks @mltony . This works for me as expected in Notepad++ with braille when moving to the next line, if last line is empty. |
|
Thanks @nvdaes! |
|
This is an interesting find. I'm afraid though that this implementation might report nonexisting blank lines when moving by line with the review cursor. I guess this clarifies why the chrome test behavior differs now. Also note that the comment is no longer accurate now. It says: I agree though that what you said in an earlier comment in the previous pr is true, namely that the last empty line of a document has a length of 0. Treating that as 1 won't work due to the highLimit in the Note also that The story length of an empty notepad classic document (i.e. a default EditTextInfo) is 1, not 0. It uses a + 1 trick, though there is an ambiguous comment saying that an off by one error is created by the + 1. I think this means no more than that this trick causes the story length to be reported one higher than the actual length. It seems that EditTextInfo doesn't treat line breaks as actual characters. A quick fix would be doing _getStoryLength + 1, but this introduces the same ambiguity as in EditTextInfo. |
I don't think so. If I read this code correctly, However having said that, I agree that any change in this low-level TextInfo implementation might cause undesired behavior somewhere else, so I'll keep an eye on any bug reports if there are any. Also updated the comment. |
|
I can't find any strange behavior with the review cursor in neither classic notepad nor NP++. NP++ improves in such a way that the review cursor can now also reach the last line, which is great. |
Co-authored-by: Leonard de Ruijter <3049216+LeonarddeR@users.noreply.github.com>
|
I just added the merge early label since I think this needs some broader testing in Alpha. |
seanbudd
left a comment
There was a problem hiding this comment.
Would we consider this an API breaking change?
Co-authored-by: Sean Budd <seanbudd123@gmail.com>
|
@seanbudd, regarding API breaking, I just wanted to mention yet again that this is also a bug. As I mentioned before, without this PR the entire textInfo API is unusable as there is no reliable way to collapse textInfo and this breaks a few of my add-ons. It would be unfortunate if we have to wait until next major release to fix a bug like that. |
|
@SaschaCowley @michaelDCurran - do you mind reviewing this so we can merge it early into 2026.1? @mltony - could you merge in master and add an entry for API breaking changes? |
|
@seanbudd, done! |
|
Thanks |
Link to issue number: Related to #18744 Follow up of #18348 Summary of the issue: When working on #18744, I again stumbled upon the fact that the story length reported by EditTextInfo is too high. This was discovered after system test failures caused by #18348, i.e. reporting of an extraneous blank at the end of the document when using NVDA review cursor. Note, this is not a bug in #18348 and was accounted for in #18744 after the test failure. To reproduce 1. Open notepad classic 2. type `a` 3. Position the caret at the end of the line 4. Press nvda+delete or nvda+numpad delete Observe that NVDA reports 50%, not 100% Observe that `nav.makeTextInfo("caret")._getStoryLength()` reports 2, not 1 Description of user facing changes: None Description of developer facing changes: None Description of development approach: Fixed the off by one errors by removing the `+ 1` cases. Testing strategy: Tested str from this pr. Known issues with pull request: None
…cess#18348)" This reverts commit 8742b3a.
Fixes #19152 Fixup for #18348, Supersedes #19203, #19171 Summary of the issue: In LibreOffice, it is not possible to use braille panning since #18348. Description of user facing changes: Panning works again in LibreOffice Description of developer facing changes: removed OffsetsTextInfo.allowMoveToOffsetPastEnd. Description of development approach: Rather than having one allowMoveToOffsetPastEnd class attribute, introduce a allowMoveToUnitOffsetPastEnd method that takes a unit.
Link to issue number:
Fixes #18320.
This is my second attempt to fix it without breaking #17430. For the reference, the first attempt was #18338, which is abandoned, and which didn't fix the root cause, but just decoupled @nvdaes's commit from TextInfo API. This PR however fixes the root cause of #17430.
Summary of the issue:
Commit 70cd311 by @nvdaes introduced a bug in TextInfo API:
TextInfo.collapse()now unnecessarily jumps to the next paragraph in Notepad++. This bug also made its way into 2025.1 release.I investigated the braille issue #17430 further and it boiled down to an issue with
OffsetTextInfo.move()implementation: it turns out that unless it moves by character, it is unable to move to the very last position in the document. FixingOffsetTextInfo.move()implementation.Description of user facing changes:
N/A
Description of developer facing changes:
OffsetTextInfo.collapse()now works correctly in Notepad++.OffsetTextInfo.move()can now move to the very last position even when unit is set to line or paragraph.Description of development approach:
In
OffsetTextInfo.move()modified the condition whenself.allowMoveToOffsetPastEndto increasehighLimitregardless of current unit - previously this would only allow when unit is character.Removed
ScintillaTextInfo.expand()override.Testing strategy:
Tested with use case provided in TextInfo.collapse(end=True) moves textInfo to the next paragraph in Notepad++ #18320.
Tested that
OffsetTextInfo.move('line', 1)can now successfully go to the very last line in Notepad++ even if the last line is empty. This should be the proper fix for Notepad++: braille doesn't move to the next line if last line is empty #17430.Known issues with pull request:
N/A
Code Review Checklist:
@coderabbitai summary