Just after NVDA restarts, Word uses UIA no matter the parameter in advanced settings panel

[CyrilleB79]

Steps to reproduce:

0. In advanced settings panel, set the "Use UI Automation to access Microsoft Word document controls" on "Only when necessary".
1. Open a Word document
2. Press NVDA+Q and restart NVDA
3. Navigate in the document with arrows
4. Press F1 to open the log and look at the properties of the current navigator object (specifically Python class mro)
5. Close the log to turn back to the Word document and navigate in it with arrows.
6. Press F1 to open the log and look at the properties of the current navigator object (specifically Python class mro)

Actual behavior:

At step 3, each time I press up/down arrow, "edit read only" is reported befeore each line. Also there are issues with table navigation. All these issues are the ones encountered with UIA in this version of Word that does not support it yet very well.

At step 4, the Word document properties indicate that it is classified as UIA:

Developer info for navigator object:
name: ''
role: Role.DOCUMENT
roleText: None
states: State.FOCUSABLE, State.FOCUSED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.Dynamic_WinwordWordDocumentWordDocumentEditableTextWithAutoSelectDetectionUIAWindowNVDAObject object at 0x08C13EF0>
Python class mro: (<class 'NVDAObjects.Dynamic_WinwordWordDocumentWordDocumentEditableTextWithAutoSelectDetectionUIAWindowNVDAObject'>, <class 'appModules.winword.WinwordWordDocument'>, <class 'NVDAObjects.UIA.wordDocument.WordDocument'>, <class 'UIAHandler.browseMode.UIADocumentWithTableNavigation'>, <class 'documentBase.DocumentWithTableNavigation'>, <class 'NVDAObjects.UIA.wordDocument.WordDocumentNode'>, <class 'NVDAObjects.behaviors.EditableTextWithAutoSelectDetection'>, <class 'NVDAObjects.UIA.UIA'>, <class 'NVDAObjects.window.winword.WordDocument'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <class 'garbageHandler.TrackedObject'>, <class 'object'>)
description: ''
location: RectLTWH(left=0, top=152, width=1349, height=554)
value: None
appModule: <'winword' (appName 'winword', process ID 5396) at address 7d3fc10>
appModule.productName: 'Microsoft Office 2016'
appModule.productVersion: '16.0.5290.1000'
TextInfo: <class 'NVDAObjects.UIA.wordDocument.WordDocumentTextInfo'>
windowHandle: 789328
windowClassName: '_WwG'
windowControlID: 0
windowStyle: 1442840576
extendedWindowStyle: 16
windowThreadID: 16064
windowText: 'Document Microsoft Word'
displayText: ''
UIAElement: <POINTER(IUIAutomationElement) ptr=0x72f8e60 at 8c215d0>
UIA automationID: 
UIA frameworkID: Win32
UIA runtimeID: (42, 789328)
UIA providerDescription: [pid:4572,providerId:0xC0B50 Main:Nested [pid:5396,providerId:0xC0B50 Main(parent link):Unidentified Provider (unmanaged:wwlib.dll)]; Hwnd(parent link):Microsoft: HWND Proxy (unmanaged:UIAutomationCore.dll)]
UIA className: _WwG
UIA patterns available: ScrollPattern, TextPattern, LegacyIAccessiblePattern

At step 5, navigation is normal, i.e. as when UIA is not activated.

At step 6, we can see that the Word document is not classified as UIA but as IAccessible:

Developer info for navigator object:
name: 'Document Microsoft Word'
role: Role.EDITABLETEXT
roleText: None
states: State.FOCUSABLE, State.MULTILINE, State.FOCUSED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.Dynamic_WinwordWordDocumentWordDocumentIAccessibleWindowNVDAObject object at 0x090F6BB0>
Python class mro: (<class 'NVDAObjects.Dynamic_WinwordWordDocumentWordDocumentIAccessibleWindowNVDAObject'>, <class 'appModules.winword.WinwordWordDocument'>, <class 'NVDAObjects.IAccessible.winword.WordDocument'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.window.winword.WordDocument'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <class 'garbageHandler.TrackedObject'>, <class 'object'>)
description: None
location: RectLTWH(left=0, top=152, width=1349, height=554)
value: None
appModule: <'winword' (appName 'winword', process ID 5396) at address 7d3fc10>
appModule.productName: 'Microsoft Office 2016'
appModule.productVersion: '16.0.5290.1000'
TextInfo: <class 'NVDAObjects.window.winword.WordDocumentTextInfo'>
windowHandle: 789328
windowClassName: '_WwG'
windowControlID: 0
windowStyle: 1442840576
extendedWindowStyle: 16
windowThreadID: 16064
windowText: 'Document Microsoft Word'
displayText: ''
IAccessibleObject: <POINTER(IAccessible) ptr=0x76a2850 at 8fd9210>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=789328, objectID=-4, childID=0
IAccessible accName: 'Document Microsoft Word'
IAccessible accRole: ROLE_SYSTEM_CLIENT
IAccessible accState: STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048580)
IAccessible accDescription: None
IAccessible accValue: None

Expected behavior:

At step 3, we should not encounter UIA bugs.

At step 4, Word document should be classified as at step 6, i.e. IAccessible properties.

Note:

A restart is required. The issue does not happen when just starting NVDA with ctrl+alt+N since the focus does not land in the Word document in this case, but on the taskbar.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2022.1rc1

Windows version:

Windows 10 20H2 (x64) build 19042.1645

Name and version of other software in use when reproducing the issue:

Microsoft® Word 2016 (16.0.5290.1000) MSO (16.0.5278.1000) 32 bits

Other information about your system:

N/A

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.

Yes, issue was already present in 2021.3.x and probably also before.

If NVDA add-ons are disabled, is your problem still occurring?

Yes, tests made without add-ons.

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Yes

[lukaszgo1]

I'm not sure I understand point 2 are you sure points 2 and 3 are in the right order? As to the point 4 this is a duplicate of #5758 (never mint it is closed the issue still occurs), and #8460. NVDA's in process code has to receive focus event to inject in process and create a binding handle, and without binding handle we fallback to UIA support for MS Word regardless if version of MS Word has good enough support for UIA or not.

[CyrilleB79]

I'm not sure I understand point 2 are you sure points 2 and 3 are in the right order?

Thanks for reporting. The STR was actually erroneous. I have modified it, replacing steps 1 to 3 by steps 0 to 3; steps 4 to 6 remain unchanged.

As to the point 4 this is a duplicate of #5758 (never mint it is closed the issue still occurs), and #8460. NVDA's in process code has to receive focus event to inject in process and create a binding handle, and without binding handle we fallback to UIA support for MS Word regardless if version of MS Word has good enough support for UIA or not.

So does it just need that it cannot be fixed? If yes, I will let NVAccess label it accordingly, e.g. with a CANTFIX label.

The issue is not so important since the workaround is just to move the focus elsewhere and then back. But it bother me sometimes when I perform tests on Word.

[Adriani90]

@CyrilleB79 is this still the case with NVDA 2023.1 RC and last MS Word version?

[CyrilleB79]

It is still the case with NVDA 2023.1rc1.

MS Word version is still the same; it has not yet been upgraded by my company but it still belong to versions supported by MS. Anyway, given the explanation, Word version should not matter if you force UIA usage to "only if necessary", i.e. use object model when possible.

[CyrilleB79]

This issues has just been discussed on the NVDA mailing list in this thread, with an initial confusion on where the issue comes from (add-on or not).

[britechguy]

I am adding a comment to this thread at the suggestion of two others, though I honestly don't think that the issue that this thread is intended to address is the only one, or perhaps the primary one, at play here. The reason I believe that is that Narrator is also not "playing at all well" with this form (or others) and I made a recording of what it's announcing and posted it on the NVDA group in the topic linked below.

I have used MS-Word fillable forms for years and with JAWS and NVDA. Both screen readers had invariably allowed me to tab through the forms, correctly announcing the various text fields, checkboxes, etc., based on the Help Text I have set up to display in the Status Bar, and that can also be brought up using F1 for that help text. NVDA is now simply not reporting either. I would suggest having a look at the topic: Call for Assistance/Replication: BusNoteForm.dotx - JAWS 2022 works, NVDA 2023.1 doesn't on the NVDA Group on Groups.io for an in-depth review of what's happening, including sound recordings I have made when working with JAWS, NVDA, and Narrator.

I would be happy to create an issue for this if this issue is not the right one. But I honestly have no idea of exactly what to report other than NVDA's not reading correctly for MS-Word fillable forms, and it used to.

[CyrilleB79]

Hi Brian

The issue you describe in your last comment is not the same as the one initially described in this issue.

For more details, I have added a new comment in the thread Call for Assistance/Replication: BusNoteForm.dotx - JAWS 2022 works, NVDA 2023.1 doesn't

So could you please open a new issue named "In Word, form labels do not read when using UIA" or something similar, with all the information of the issue template? Thanks.

[Adriani90]

So maybe this is the right issue to investigate the UIA enforcement issue on older MS Office versions, it seems it impacts also Office 2016 although there is simple work around to move the focus back and forth. cc: @lukaszgo1, @XLTechie. @CyrilleB79 are you still seeing this issue with NVDA 2024.1 Beta?

[britechguy]

Addendum, but at the beginning: I'm leaving what follows because I think it's important that it remain on record, but I will acknowledge it didn't need to be said "now." I had accidentally not deleted the email from GitHub that got triggered by Cyrille's comment of April 29, 2023, so thought it was a fresh one. That is what triggered what follows on February 24, 2024:

What follows is probably going to come across as more aggressive than it's meant to, but I don't know how else to put it.

While I am a "more sophisticated than usual" end user about all things programming, I am still an end user. Issues often get reported more than once, or in slightly different spins, that all tie into the same root cause.

Github has the ability to "pull all the threads together" in terms of related issues making reference to each other. I cannot see any point in me, or any user, opening a new issue that is, at its core, just a retread of an existing issue or issues. If someone on the development team really feels that an additional issue, with a new title that references UIA is needed, then they should open it, making reference in it to any and all related issues that should be reviewed that are tied to it.

That should not ever be an end user's role, ever.

[lukaszgo1]

Let's avoid guesses! We don't know why UIA was used by the person who reported it misbehaves in Office 2013. Note that this issue still occurs but only if you haven't moved focus away from the document, and it was focused when restarting NVDA.

[CyrilleB79]

@CyrilleB79 are you still seeing this issue with NVDA 2024.1 Beta?

Yes, with NVDA 2024.1beta7, issue logically still present.