Skip to content
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

Open
Qchristensen opened this issue Mar 11, 2022 · 4 comments
Assignees
Labels
triaged Has been triaged, issue is waiting for implementation.

Comments

@Qchristensen
Copy link
Member

Steps to reproduce:

  1. Have UIA enabled in NVDA's Advanced settings
  2. Open a blank document in Microsoft Word
  3. Type "1. " (one, dot, space), then type something.
  4. Press ENTER.
  5. Press NVDA+up arrow / NVDA+l to read the current line
  6. Type something
  7. Press NVDA+up arrow / NVDA+l to read the current line

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

michaelDCurran added a commit that referenced this issue Mar 15, 2022
… 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.
@michaelDCurran
Copy link
Member

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:

FieldCommand controlStart with {'runtimeID': (42, 1181958, 4, 16), '_startOfNode': False, '_endOfNode': True, 'role': <Role.LISTITEM: 16>, 'states': set(), 'nameIsContent': False, 'name': '1.', 'description': '', 'level': 1}, FieldCommand formatChange with {'language': 'en_AU', 'section-number': 1, 'page-number': '1'}, '2.',

And therefore we don't fetch the text and place it as the line-prefix in the formatField.
Further investigation will need to be made as to why exactly the UIA textRange of the line start does not compare equal with the UIA textRange start of the listItem.
No doubt it is porbably because the listItem in question is still the old list item. Note that in the example fields above, the name is '1.' where it should be '2.' like its inner text.

@Qchristensen
Copy link
Member Author

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).

@LeonarddeR
Copy link
Collaborator

@Qchristensen Could you still reproduce step 5? Since I can't, i.e. NVDA reads the number correctly.

@XLTechie
Copy link
Collaborator

XLTechie commented May 15, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triaged Has been triaged, issue is waiting for implementation.
Projects
None yet
Development

No branches or pull requests

5 participants