Ensure tabbing through messages in Windows Mail does not get stuck on the same link #15234
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Link to issue number:
Fixes #15211
Summary of the issue:
After merging of pr #14611, tabbing through a message in Windows Mail would cause the caret / focus to get stuck and not move forward to the next element in tab order.
This seems to be because BrowseModeDocument's gainFocus event updates the caret to the position of the element in the document that just gained focus. This is appropriate for web documents where NVDA manages the caret itself, but not for documents where the caret is managed by the application, such as the MS Word mail message viewer.
This has most likely been a problem in some way for a long time, but pr #14611 made it much more obvious as it greatly increased the amount of focus events within documents now spoken / handled.
Description of user facing changes
NVDA no longer gets stuck when tabbing through a message in Windows Mail.
Description of development approach
Suppressing of caret movement in BrowseModeDocument's gainFocus event is controled by a new private variable on the CursorManager class. It is False by default, which does not allow the caret movement to occur. However, for ReviewCursorManager and VirtualBuffer classes, it is True, allowing the existing caret movement behaviour, as in these situations the caret is managed entirely by NVDA.
This then means that in the cases where a CursorManager is used that is not VirtualBuffer or ReviewCursorManager, which is just Microsoft Word browse mode, NVDA will not move the caret itself on gainFocus events, as the application itself will already do this.
Testing strategy:
Known issues with pull request:
This is a very quick fix, that addresses a specific issue for a 2023.2 beta. It may be possible to abstract this wanted behaviour in a cleaner way from the ground up, but this is the smallest code change with the least impact.
Change log entries:
New features
Changes
Bug fixes
For Developers
Code Review Checklist: