files-community
Bug: Window doesn't receive focus when started via win+e
Description
Keyboard shortcuts don't work unless the user focuses on certain parts of the UI. So far, I've found that the sidebar and main content panel (where the actual files and folders are listed) do accept keyboard shortcuts, but nowhere else does to my knowledge. This can cause unexpected behavior when users can only sometimes use shortcuts, depending on which section of the UI happened to be clicked/focused on last.
Specifically the issue I have is that I can't use Ctrl+L as soon as I opened Files to focus on the address bar.
Alternatively, if this is expected behavior and it's not desirable to allow keyboard shortcuts under all circumstances (such as while typing in the address bar or search bar), another solution could be to automatically put focus on the main content panel on startup so these shortcuts work immediately.
Steps To Reproduce
- Open Files.
- Without clicking anywhere, attempt to execute a keyboard shortcut. For this example, let's say Ctrl+L.
- Nothing happens.
Files Version
3.8.0.0
Windows Version
Win11Pro 23H2 22635.4800
User ID
098f73da-2b32-488b-99e1-f9b3f5b80dfd
Log File
Thanks for the report, can you see if this is an issue in the preview version. https://files.community/download If it is, how are you opening Files? Keyboard shortcuts only work if the window is focused.
It seems to only be an issue when opening with Win+E (after having Advanced > "Set Files as the default file manager" turned on). The same behavior occurs in stable and preview.
I assume it is focused based on the styling of the taskbar, but I've had issues in the past with Windows Terminal not receiving input when opening, even though the taskbar appeared as though it was focused, so it's possible my OS is messed up in some way. I'll attach a video within 24 hours with a demonstration.
https://github.com/user-attachments/assets/c3a4481f-8d75-45f5-99bd-71a0ca1e4b08
So much for 24 hours... :/
When I first submitted this bug report, opening Files from the Start Menu caused this bug to occur. When asked to clarify when it occurred, I checked again and paid more attention. That second time, the only way to cause the issue was with Win+E. However, while recording the issue, it now happens again with both of these methods. Keep in mind I am using ExplorerPatcher to revert my Start Menu to the Windows 10 version while being on Windows 11, so the Start Menu method may not be an issue for average users.
I demonstrate here that, although Files is considered focused by Windows (see taskbar icon), no keyboard shortcuts pass through to some part of the application. I say "some part" because the application does receive Alt+F4 and handle it appropriately. For this reason, I don't believe "Window doesn't receive focus" is completely accurate, as it seems the window itself receives focus, but perhaps not the content.
i'm also able to reproduce it , after pressing Ctrl+L the address bar get the focuse and after enter the focus switched to the NEW Button
@lakani Thats not what this issue is, this is about when opening Files. If you want something else to focus after entering a path please make a new issue using feature request template
Hope this gets fixed asap. I rely on the keyboard for everything, and not getting focus with Win+E really slows me down
@nwalkewicz @arfadex Is this still an issue on v4.0.11 https://files.community/download
@Josh65-2201 Apologies, I switched to Linux early this year and haven't used Windows lately. Apparently I borked my desktop's Windows boot partition at some point, so I couldn't test it out when I tried the other day. I still have the original Windows laptop I created the issue with, I'll check and get back to you.
@Josh65-2201 Yes, I can confirm the issue seems to be identical as before (with version 4.0.11.0).
This is 100% reproducible.
Win+E starting the app does not shift focus to the app.
- Close all windows.
- Win+E
- Ctrl+F <--- does not work, because window is not focused.
Change the tag from "needs reproducing" to reproducible.
Files.Bug.Report.mp4 So much for 24 hours... :/
When I first submitted this bug report, opening Files from the Start Menu caused this bug to occur. When asked to clarify when it occurred, I checked again and paid more attention. That second time, the only way to cause the issue was with Win+E. However, while recording the issue, it now happens again with both of these methods. Keep in mind I am using ExplorerPatcher to revert my Start Menu to the Windows 10 version while being on Windows 11, so the Start Menu method may not be an issue for average users.
I demonstrate here that, although Files is considered focused by Windows (see taskbar icon), no keyboard shortcuts pass through to some part of the application. I say "some part" because the application does receive Alt+F4 and handle it appropriately. For this reason, I don't believe "Window doesn't receive focus" is completely accurate, as it seems the window itself receives focus, but perhaps not the content.
what did you use to make your bug report video?
@AMDphreak OBS, Keyviz, and either Blender or Kdenlive for editing.
@yaira2 I'll get back to you on that later today when I get a chance to try it out.
@yaira2 Hey sorry, just got around to trying this out. No application-level keys seem to do anything. Tab does nothing, F5 does nothing, Ctrl-R does nothing, etc. Only stuff handled outside by Windows itself seems to do anything. That explains why Alt-F4 works; I assume it's not that Files handles the key event Alt-F4, but instead handles the WM_CLOSE event.