Repository: nvaccess/nvda

Issue:
nvda not reading start menu button

### Steps to reproduce:
put the keyboard focus on the desktop.
press tab
### Actual behavior:
nvda is muted and error sound is heard interruptly
### Expected behavior:
nvda should advertise start button.
### System configuration
#### NVDA installed/portable/running from source:
instaled
#### NVDA version:
nvda.exe, NVDA alpha-25456,6cf16d1a

#### Windows version:
11 10.0.22000.675
#### Name and version of other software in use when reproducing the issue:

#### 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.
yes
worked correctly on the alpha copy previously installed on this computer which was 24360
#### If 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
log:
[start.txt](https://github.com/nvaccess/nvda/files/8742056/start.txt)



Discussion:
Hi, this is odd – Start button is somehow seen as StartButton class instance. This should not be so in Windows 11 as Start button is seen as UIA element, not an IAccessible object. Have you tried logging out and logging in from this computer and see if that makes a difference? Thanks.


thanks for the feedback.
 yes, I have already exited the current user, and entered the user again.
 This machine has no other user accounts.
 The machine has already been turned off, restarted.
 In fact, a little while ago, after I opened the ticket, I updated this machine to build 22621 and this error persists.
Hi,

Okay, can you try the alpha releases between 25360 and 25456 and see which version is causing this problem? I suspect it could come from my work on Windows 11 UI design changes or something else. Alternatively, do the following as exactly as I say:

1. Press Windows+B to go to notification chevron button.
2. Press Control+NVDA+Z to open Python Console.
3. Type the following code fragment as exactly as shown (press Enter after each line):

import winUser
focus
winUser.getClassName(winUser.getAncestor(focus.windowHandle, 2))

Then press F6 and copy and paste the entire output text. I'm interested in seeing what we find out about Windows 11 UI design elements on this particular computer. Windows 11 UI elements should be UIA elements, not IAccessible (as mentioned previously).

Also, the log fragment tells me that IAccessible handler cannot find specific attribute from what NVDA thinks is an IAccessible object (Start button). The object in question is seen as both IAccessible and UIA element becaue:

1. StartButton class (part of File Explorer app module) is actually an IAccesible object.
2. Windows 11 UI elements are UIA objects, not IAccessible. Normally if all add-ons are disabled, NVDA should use whatever the default File Explorer app module says about Start button (presented as a UIA toggle button).

I expect we will get reports from some who may experience this on their Windows 11 systems (I expect it can be a minority of users but I'm assuming the worst).

Thanks.
>>> import winUser
>>> focus
<NVDAObjects.Dynamic_ClipboardCommandAnnouncementNVDAObjectExRecognizableFileObjectUIAWindowNVDAObject object at 0x01234E50>
>>> winUser.getClassName(winUser.getAncestor(focus.windowHandle, 2))
'Shell_TrayWnd'

I hope it's solid
Hi, is this with all add-ons disabled? At least the ancestor class name (the last line) is what I expected, but the first part (where I see ClipboardCommandAnnouncement) is a little bit concerning. Can you try this procedure again after you restart NVDA with add-ons disabled? Thanks.


nvda_snapshot_alpha-25447,23f2d788
by my tests this was the first version that presents the problem
>>> import winUser
>>> focus
<NVDAObjects.UIA.UIA object at 0x05588610>
>>> winUser.getClassName(winUser.getAncestor(focus.windowHandle, 2))
'Shell_TrayWnd'


with add-ons disabled
Hi,

That's what I thought. I'm looking at changes between 25430 and 25447 to understand what's going on.

Thanks.
thank you very much, i appreciate it.
Hi,

Can you try the following Windows App Essentials add-on try build which disables Windows 11 UI elements fix to see if that is indeed the root cause? To test, install the try build of this add-on, restart NVDA (with add-ons enabled), and try tabbing to Start button and see if NVDA says something.

Add-on try build: https://github.com/josephsl/wintenApps/releases/download/22.05/wintenApps-tryIssue13717.nvda-addon

Thanks.
perfect @josephsl , this build of the windows app  Essentials  add-on works correctly
Hi,

So NVDA does announce something when you tab to Start button... Can you try the following:

1. Open Add-ons Manager (NVDA menu/Tools/Manage add-ons (in English)).
2. Disable all add-ons except Windows App Essentials.
3. Close Add-ons Manager and say "yes" when asked to restart NVDA.
4. Go to desktop (Windows+D).
5. Tab to Start button and do not press Enter.
6. Press NVDA+F1 to show the developer info for navigator object (Start button, in this case).
7. Copy and paste the developer info here.
8. Close log viewer.
9. Open Add-ons Manager and enable all add-ons again.
10. Close Add-ons Manager and say "yes" when NVDA asks you to restart.
11. Go to desktop again (Windows+D).
12. Press Tab to go to Start button but do not press Enter.
13. Press NVDA+F1 to open developer info.
14. Copy and paste the developer info for Start button here.

I'm interested in seeing what NVDA says about Start button's developer info and compare between the two scenarios. Ideally NVDA should NOT say "StartButton" as part of Python MRO (method resolution order) for Windows 11 Start button. If StartButton (class) is indeed part of MRO, this suggests something odd is happening on your computer that causes NVDA to see something when it should not, or something odd is indeed happening caused by the partial fix for #13506. If it is indeed the latter, I can either provide a follow-up that will ask IAccessible handler to do something about the exception you are seeing, or revert the fix at the cost of loss of mouse and touch interaction for Windows 11 shell elements.

Thanks.
I did the 2 tests and attached the 2 logs, I put the complete log because there is a lot of information and I didn't know exactly what would be relevant, but I believe that what you want is right at the end of the 2 files.
vote for the solution where you say:
provide a follow up that will ask the IAccessible handler to do something about the exception you are seeing
[startaddonsall.txt](https://github.com/nvaccess/nvda/files/8748709/startaddonsall.txt)
[startaddonswinapp.txt](https://github.com/nvaccess/nvda/files/8748710/startaddonswinapp.txt)

Hi, there is a third solution: telling NVDA to treat “Start” window class name as IAccessible always. To verify, can you try pressing Windows+T to go to Taskbar, press NVDA+F1 (which should hopefully present dev info for taskbar items), and paste the dev info (or the log) as an attachment? I’m wondering if Taskbar items are also seen as IAccessible objects (just to double-check, and if yes, something odd is really happening). Thanks.


Hi,

In addition to the Taskbar log, can you also try the following Windows App Essentials add-on try build:
https://github.com/josephsl/wintenApps/releases/download/22.05/wintenApps-tryIssue13717Ver2.nvda-addon

This build keeps Windows 11 shell element interaction fix while trying to detect Start button noted on this particular system. If things go well, NVDA should announce Start button when you tab to it, and if not, it might be time for me to either revert #13506 or return to it in July.

Thanks.
Perfect, so maybe the third option is better, now I vote for it.
Follow the attached log, I hope so.
Thank you very much, I'm available.
[tasktoos.txt](https://github.com/nvaccess/nvda/files/8749390/tasktoos.txt)

Hi, so I guess we can assume that NVDA does announce Start button when you tab to it… I’ll do something about this within the next 24 hours (and to other folks: for the next six weeks, please write me a private email if you notice me writing comments for newer Windows 10/11 issues; this is for accountability to really get my mind off NVDA throughout June). Tanks.



Resolving patch:
diff --git a/source/appModules/explorer.py b/source/appModules/explorer.py
--- a/source/appModules/explorer.py
+++ b/source/appModules/explorer.py
@@ -530,6 +530,9 @@ def isGoodUIAWindow(self, hwnd):
 				"Shell_InputSwitchTopLevelWindow",  # Language switcher
 				"XamlExplorerHostIslandWindow",  # Task View and Snap Layouts
 			)
+			# #13717: on some systems, Windows 11 shell elements are reported as IAccessible,
+			# notably Start button, causing IAccessible handler to report attribute error when handling events.
+			and winUser.getClassName(hwnd) != "Start"
 		):
 			return True
 		return False


Test patch: