Font information not read in Cell Format dialog in Excel 2016 / 365

Qchristensen commented 4 years ago

Steps to reproduce:

In any workbook, press CONTROL+1 to open the Cell format dialog.
Press CONTROL+TAB until the focus is on the Font page.
Press TAB to move through Font, Font Style and Size.
Use the arrow keys to change the value of any of those values.

Actual behavior:

At steps 3 and 4, NVDA reports "Blank" (occasionally it read one value, but it was not consistent - eg at one point it read "Bold", and another time it read "Italic" when moving through the font style list).

NVDA didn't show an error in the log when moving through the dialog, but when first opening it recorded this:

IO - inputCore.InputManager.executeGesture (17:39:21.564) - winInputHook (5024):
Input: kb(laptop):control+1
DEBUGWARNING - NVDAObjects.window.excel.ExcelBrowseModeTreeInterceptor._get_isAlive (17:39:21.789) - MainThread (11956):
could not compare sheet names
Traceback (most recent call last):
  File "NVDAObjects\window\excel.pyc", line 463, in _get_isAlive
  File "comtypesMonkeyPatches.pyc", line 82, in new__getattr__
  File "comtypes\client\lazybind.pyc", line 168, in __getattr__
  File "comtypes\automation.pyc", line 729, in _invoke
  File "comtypesMonkeyPatches.pyc", line 26, in __call__
_ctypes.COMError: (-2147418111, 'Call was rejected by callee.', (None, None, None, 0, None))
DEBUG - treeInterceptorHandler.killTreeInterceptor (17:39:21.789) - MainThread (11956):
Killed treeInterceptor: <NVDAObjects.window.excel.ExcelBrowseModeTreeInterceptor object at 0x00D60490>
IO - speech.speak (17:39:22.199) - MainThread (11956):
Speaking [LangChangeCommand ('en_GB'), 'Format Cells', 'dialog', 'Color:']
DEBUG - synthDrivers.oneCore.SynthDriver._processQueue (17:39:22.199) - MainThread (11956):
Begin processing speech
IO - speech.speak (17:39:22.203) - MainThread (11956):
Speaking [LangChangeCommand ('en_GB'), 'Format Cells', 'tab control', 'Font']

There was a similar previous issue: https://github.com/nvaccess/nvda/issues/7758 which was noted as fixed in 2018.4. (I'm not sure if this is a regression of that fix, or a different issue with the same effect).

Expected behavior:

NVDA should read each option.

System configuration

NVDA installed/portable/running from source:

NVDA version:

NVDA 2019.1.1 through to 2020.2 and alpha-20739,89c84b84 (It does work with NVDA 2018.4)

Windows version:

Windows 10 (64-bit) Version: 1903 Build 18362

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

I can replicate using Office 365 (64-bit) Version: 16.0.13029.20232

A user (Gowri Oraganti via email) initially reported this using Office 2016.

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.

As above

If addons are disabled, is your problem still occuring?

No add-ons

Did you try to run the COM registry fixing tool in NVDA menu / tools?

comanna commented 4 years ago

Quentin,

I can confirm that his is my experience also.

ivnc commented 4 years ago

A Spanish-speaking user has reported the same issue and it is fully reproducible, at least by me. The user is using Office 2016 and me 365.

Regards.

ivnc commented 4 years ago

I should also add that reading character by character, with left/right arrows, reporting of selected option seems to be correct.

Regards.

Carlos-EstebanM commented 4 years ago

Hi all. A user in the Spanish community report that this problem also is reproducible in NVDA 2020.3 beta1. The user opens the file in Excel (NVDA running with add-ons disabled), in a cell press applications key, after press f (shortcut in Spanish for fount) and enter. The dialog is the same, and the problem also is the same. What is a possible solution? Developers, do you can check it? Regards.

Qchristensen commented 4 years ago

It seems to be to do with the text being selected. As you tab to a new edit field, or use the up and down arrow keys to change, eg font name, the new option is selected. The selected text does not seem to be exposed. As soon as you deselect text, it is able to read the contents of the current edit.

Qchristensen commented 4 years ago

A bit more info I recieved on this one: "Using Accessibility Insights (or Inspect) I can see why there is a difference in behavior when text is selected versus not:

Tabbing between the controls puts focus on the Edit control that has a Value matching the selected text Clicking between the controls puts focus on the pane that has a Name matching the unselected text

So it seems NVDA is not reading the value of the edit control when it gets focus (or changes), but it is reading the name of the pane when it gets focus. Though NVDA mouse hover is reading both the control name and contents regardless of selection. And surprisingly, Narrator is reading both, so it seems to be something unique to NVDA focus presentation."

britechguy commented 3 years ago

This behavior is also present if you open the font dialog for a cell using CTRL+SHIFT+F. I'm being told the values are blank when they definitely are not blank for font and style, I stopped checking after that.

Using the NVDA+f command is giving me "No caret." This is under 2020.3, installed.

Adriani90 commented 3 years ago

cc: @lukaszgo1, @CyrilleB79

lukaszgo1 commented 3 years ago

The "no caret" issue would be fixed when #11914 would be merged. As to not reporting content of edit fields in format cell dialog I cannot reproduce in Excel 2010 so it is probably unique to 2016 and later.

britechguy commented 3 years ago

If you'd like for me to check what happens in Excel 2013 I can do so since I happen to have a machine with Office 2013 installed at the moment.

While it's interesting and useful to know what does and doesn't work in versions of Office prior to 2016, it's 2016 and later that really matter at the moment, since 2016 serves as the code base for 2019 and 365 successors.

Qchristensen commented 3 years ago

This is still an issue in Office 365 and seems to affect any dialog with selectable / editable text, eg the Define name dialog (context menu then a). This is being reported as a primary reason why at least one organisation is not using NVDA.

ivnc commented 2 years ago

Yes, it seems a general issue with most editable fields in dialogs. In our case, reporter works at a public body and asks us with every NVDA release for the evolution of this issue, it would be great to have news soon.

Thanks.

Qchristensen commented 2 years ago

Just a quick note, this is still reproduceable with:

NVDA 2021.3.1

Windows 10 (64-bit) Version: 21H2 (2009), Build: 19044.1466

Office 365 (64-bit) Version: 16.0.14729.20254

Also, whether NVDA set to use UIA in Excel or not seems to make no difference.

ivnc commented 1 year ago

Hello, are there any news on this? Apparently it is still reproducible. Thanks!

ABuffEr commented 1 year ago

Hi, if it can help, I noticed that moving with navigator object on these fields returns the correct object, with name/accName e.g. "Character type" (I'm translating) and value/accValue "Calibri"; moving with tab, instead, returns an object with name "Character Type", value None, accName "Calibri" and accValue None. So fix could be quite simple, at least in the static situation (no idea when changing the value), but I don't know whether the other object info are sufficient to catch it in an unique way...

Adriani90 commented 3 months ago

It seems there are two control fields for each of these. An edit field where you can enter / choose the style, font size, etc., and a list which is next to the edit field and which shows the actual value which has been chosen. It seems NVDA only tracks the edit field when navigating, but the actual accessible value should be taken from the list next to the edit field. You can check this by using object navigation. cc: @michaelDCurran

nvaccess / nvda