-
-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Numbering not read for new or blank items in a list in Word with UIA enabled #13462
Comments
… at the end of the document (#13477) Fixes #13458 fixes #13459 Partial fix for #13462 Summary of the issue: In MS word via UIA: When at the end of a document and arrowing left or up into existing content, or when on a blank table cell and arrowing, tabbing or NVDA table cell navigating back into a cell with content, NVDA reports all formatting set for automatic reporting, even if the formatting between the blank position and the existing content does not differ. For example, when on a blank table cell and pressing control+alt+leftArrow and moving to a cell with existing content, NVDA will report "section 1, page 1" before reporting the content of the cell. If the user has enabled automatic reporting of font color, then the font color will also be included. This is due to the fact that NVDA fails to fetch formatting for blank table cells, and the insertion point at the end of the document. But still clears the formatting cache. Thus when fetching valid formatting after this, all the formatting is treated as changed. Related somewhat to this, is the fact that new list items are not announced when being inserted at the end of the document. Description of how this pull request fixes the issue: • UIAHandler.utils.iterUIARangeByUnit: when at the end of the document, it is impossible to move by unit at all. Thus if we cannot walk at all, then just yield the original range. This ensures that we do actually fetch text and fields for the insertion point at the end of the document. • UIATextInfo's _getTextWithFields_text: don't refuse to yield a formatField before an empty text string. This is true on empty table cells and at the end of the document.
It seems that as the bullet is inserted, fetching that line, the start of the line is not the start of the bullet. Thus _startOfNode is False:
And therefore we don't fetch the text and place it as the line-prefix in the formatField. |
This is still an issue with NVDA 2023.3 and Office 365 (64-bit) Version: 16.0.16924.20124 on Windows 11 (64-bit) Version: 22H2, Build: 22621.2428 (Reported by a user today). |
@Qchristensen Could you still reproduce step 5? Since I can't, i.e. NVDA reads the number correctly. |
@LeonarddeR, this appears to have been partially fixed in #13477, as referenced above.
@Qchristensen, can you perhaps edit this to highlight the part that still needs fixed, and the updated STR?
In Word 2019, with NVDA 2024.2, step five's result can no longer be replicated. Step 4's result can be, however; though the setting for UIA is no longer just "enabled"/"disabled".
|
Steps to reproduce:
Actual behavior:
At step 4, the focus moves to a new line, Word automatically adds "2. ". NVDA does not report anything.
At Step 5, NVDA reports "blank".
At step 7, NVDA report "2. text" (where text is whatever you typed).
With UIA disabled:
At step 4, NVDA reads "two dot"
At step 5, NVDA reports "two blank".
At step 7, NVDA reports "2. text" (the same as with UIA enabled).
Expected behavior:
NVDA should read the numbering the same as it does with UIA disabled.
System configuration
NVDA installed/portable/running from source:
NVDA version:
2021.3.3 Installed
Windows version:
Windows 10 (64-bit) Version: 21H2 (2009), Build: 19044.1586
Name and version of other software in use when reproducing the issue:
Office 365 (64-bit) Version: 16.0.14931.20118
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
No
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Yes
The text was updated successfully, but these errors were encountered: