Fix File Explorer search box losing focus after Ctrl+F

[cary-rowen]

Link to issue number:

Fixes #20021

Summary of the issue:

In File Explorer on Windows 10, pressing Ctrl+F should move focus directly to the search edit field. Since NVDA 2026.1 beta, NVDA first reports the search edit field, but then reports a pane, so users need to press Ctrl+F a second time before they can reliably type in the search box.

This is a regression from #19117. That PR removed several old Windows 8.x Start screen workarounds from the Explorer app module, including SearchBoxClient. Although that class was described as a Windows 8 workaround, it was still filtering a redundant File Explorer search band focus event. On Windows 10, the redundant object has:

role == controlTypes.Role.PANE
windowClassName == "Search Box"

Description of user facing changes:

Same behavior as before 2026.1Beta.

Description of developer facing changes:

Restores a small Explorer app module overlay for File Explorer search band pane objects. The overlay suppresses redundant IAccessible focus events from Search Box and UniversalSearchBand pane objects.

Search Box has been confirmed on Windows 10. UniversalSearchBand is retained from the pre-#19117 filter because it appears to be another Explorer search band class, and the match is still limited to IAccessible pane objects.

Description of development approach:

This keeps the #19117 cleanup intact, except for the part that affected File Explorer search focus. The Windows 8 Start screen tile, group, launcher, and suggestion overlays are not restored.

Testing strategy:

Manual testing:

1. Start NVDA with add-ons disabled.
2. Open File Explorer on Windows 10.
3. Move focus to the file list.
4. Press Ctrl+F.
5. Confirm that NVDA reports the search edit field and does not then report pane.
6. Confirm that typing immediately enters text into the search box.

Known issues with pull request:

None known.

Code Review Checklist:

• Documentation:
  • Change log entry: Not included; this is a small regression fix.
  • User Documentation: Not needed.
  • Developer / Technical Documentation: Not needed.
  • Context sensitive help for GUI changes: Not applicable.
• Testing:
  • Unit tests: Not included; this depends on Explorer focus events.
  • System (end to end) tests: Not included.
  • Manual testing: Planned / required on Windows 10 File Explorer.
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers: Not applicable.
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[cary-rowen]

cc @josephsl

I apologize for bothering you, since you are the author of #19117.

Do you know if UniversalSearchBand might exist in Windows 10?

Thanks

[josephsl]

Hi,

Looks like a regression from my own File Explorer cleanup work. I thought universal search band was a Windows 8.x thing but looks like it should not have been removed. This issue is not seen in Windows 11.

Keep in mind that Windows 10 is in extended security updates phase.

Thanks.