Skip to content

File Explorer search box loses focus to a pane after pressing Ctrl+F in NVDA 2026.1 #20021

@cary-rowen

Description

@cary-rowen

Brief summary

In Windows File Explorer, pressing Ctrl+F to open the search field does not leave focus in the search edit box on the first attempt with NVDA 2026.1 beta. NVDA first announces the search box, but then immediately announces a Pane object, and the search edit field is not the effective focus. Pressing Ctrl+F a second time focuses the search box correctly.

This appears to be a regression in NVDA 2026.1. I could not reproduce it with NVDA 2025.3.3.

Steps to reproduce

  1. Start NVDA 2026.1 beta with add-ons disabled.
  2. Open Windows File Explorer.
  3. Navigate to any folder and ensure focus is in the file list / item view.
  4. Press Ctrl+F once.
  5. Observe NVDA speech and whether the search edit box keeps focus.
  6. Press Ctrl+F a second time.
  7. Observe that the search edit box is focused correctly after the second key press.

Actual behavior

After pressing Ctrl+F once, NVDA announces the search box and then immediately announces a pane:

Input: kb(laptop):control+f
NVDA Speech:
"搜索框 编辑框 在 beta 中搜索 空白"
"窗格"

The search edit box does not keep focus after the first Ctrl+F. Pressing Ctrl+F again focuses the search box:

Input: kb(laptop):control+f
NVDA Speech:
"搜索框 编辑框 在 beta 中搜索 空白"

Developer info after the second Ctrl+F shows that the focused object is the File Explorer search edit box:

name: '搜索框'
role: EDITABLETEXT
states: FOCUSABLE, FOCUSED
hasFocus: True
UIA automationID: SearchEditBox
UIA className: SearchEditBox

Expected behavior

Pressing Ctrl+F once in Windows File Explorer should move focus to the search edit box and keep it there, so the user can immediately type a search query.

NVDA should announce the search edit box, for example:

"搜索框 编辑框 在 beta 中搜索 空白"

It should not move focus to or announce a Pane object after the search box is opened.

NVDA logs, crash dumps and other attachments

log.txt

System Configuration

NVDA type

portable copy.

NVDA version

NVDA 2026.1beta13 AMD64

Have you tried any other versions of NVDA? If so, please report their behaviors.

  • NVDA 2026.1beta13 AMD64: issue occurs.
  • NVDA 2025.3.3: issue could not be reproduced; pressing Ctrl+F once focuses the File Explorer search box as expected.

Windows version

Windows 10 22H2, build 10.0.19045.7184, AMD64

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

Windows File Explorer / explorer.exe

From NVDA developer info:

appModule.productName: 'Microsoft® Windows® Operating System'
appModule.productVersion: '10.0.19041.4522'
windowClassName: 'DirectUIHWND'
UIA frameworkID: DirectUI
UIA providerDescription: [pid:10024,providerId:0x0 Main(parent link):Unidentified Provider (unmanaged:explorerframe.dll)]

Other information about your system

None

Troubleshooting steps

Does the issue still occur after restarting your computer?

I have restarted my computer and the issue still occurs.

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

I have restarted NVDA with add-ons disabled and the issue still occurs.

Does the issue still occur after you run the System Accessibility Repair Tool in NVDA's tools menu?

I have run the System Accessibility Repair Tool and the issue still occurs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bug/regressionfeature/windows-explorerWindows start menu, explorer, and other in-box functionality.p3https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#prioritytriagedHas been triaged, issue is waiting for implementation.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions