Incorrect table end markers in Word 365

[dkager]

Steps to reproduce:

1. Open a new document in Word 365 (tested in November 2023).
2. Go to Insert --> Table --> 3x3 Table.
3. Type 'Foobar' (or other text) in each cell.
4. Move the cursor onto the 'b' in Foobar in any cell.

Actual behavior:

At step 2:

r1 c1 tbl end tbl r1 c3 r2 c3 tbl end tbl r3 c3

At step 3:

r1 c1 Foobar tbl end tbl end tbl r3 Foobar c3 Foobar tbl

At step 4:

r1 c1 Foo tbl end bar tbl rc Foobar c3 Foobar

Expected behavior:

The correct braille markers (e.g. tbl and tbl end) should be shown in the correct places (e.g. at the start and end of the entire table). Note that I did not provide details for every table cell. They show up similarly in braille. It seems that the last column/row has special behavior compared to the other cells.

NVDA logs, crash dumps and other attachments:

N/A

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2023.3rc2

Windows version:

Windows 10 22H2 (10.0.19045) workstation AMD64

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

Microsoft® Word for Microsoft 365 MSO (Version 2310 Build 16.0.16924.20054) 32-bit

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: 2023.2 has the same behavior. 2023.1 works as expected. Also reproduced on another computer and other OS/Office language.

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.

[LeonarddeR]

I assume this was tested while UIA was active in Word? Could you confirm this by changing the state of the advanced setting Use UI Automation to access Microsoft Word document controls?

[dkager]

Sorry, should've said that. This is with UIA enabled (either the default setting or forced UIA).

[dkager]

This appears to be a more generally occurring issue. Another set of STR:

1. Open Microsoft Teams Classic.
2. Go to a chat window and focus the input area.
3. Add a quote (i.e. with > at the start of a line).
4. Type some text.
5. Place the cursor somewhere in the middle of the text.

You will now unexpectedly get "bqt end" at the cursor location.

[dkager]

I tried NVDA 2023.1 again, this time on Windows 11 23H2. I just went with the launcher, so it ran on top of my existing configuration from 2023.3.3. I found that the problem was present in this version and configuration, contrary to what I wrote earlier. I went back as far as NVDA 2021.2 and could reproduce the problem. So perhaps the problem is within Microsoft Word or in a specific NVDA configuration item.

[Nael-Sayegh]

Hello, I have started using tables in Microsoft 365 and I always encounter the same problem with NVDA 2024.3. UIA is being used, and it's a really annoying issue, especially since I use tables while reading my lessons during my teaching sessions. It makes studying really complicated. This only happens with UIA; there are no issues while browsing the web. @LeonarddeR Has anyone made any progress on this issue?

[Adriani90]

cc: @michaelDCurran, @gerald-hartig given so many issues still open with regards to UIA, it might make sense to change the default behavior to "only when necessary". See also https://github.com/nvaccess/nvda/discussions/16600 for a comprehensive list of open issues related to UIA in MS Office.

[Nael-Sayegh]

@Adriani90 I set the UIA usage parameter to 'only if necessary', and it’s true that it solved my problem with the tables. I agree that this parameter should be set by default because there are really many issues, especially with the tables.

[LeonarddeR]

I really want to use UIA with word but this issue is driving me nuts now. I'll try to come up with a quick fix if I can, but i need to debug first.

[LeonarddeR]

@michaelDCurran I created some debugging info using this diff. I noticed that i had the < and > swapped, but that's below the log statement so doesn't make a difference for the output below.

Here is what happens when navigating through the table

ERROR - NVDAObjects.UIA.UIATextInfo._getTextWithFieldsForUIARange (15:27:17.286) - MainThread (16712):
parentElement: item, 2, -3
ERROR - NVDAObjects.UIA.UIATextInfo._getTextWithFieldsForUIARange (15:27:17.294) - MainThread (16712):
parentElement: table, 6029412, 6029412
ERROR - NVDAObjects.UIA.UIATextInfo._getTextWithFieldsForUIARange (15:27:17.302) - MainThread (16712):
parentElement: edit, 2, -6
ERROR - NVDAObjects.UIA.UIATextInfo._getTextWithFieldsForUIARange (15:27:17.313) - MainThread (16712):
parentElement: page, 2, -6

As you can see here, CompareEndpoints goes entirely mad on the table. I assume this is a bug in Word and there's nothing we can do about this other than disabling table end markers in braille. Not to mention that this is most likely an explanation for more issues in Word.