Feature: Support valid URL percent encoding conversions in the address bar

[shakrunk]

What feature or improvement do you think would benefit Files?

Sometimes I might have a file open in my browser, like a pdf, image, html page, etc. when I'll realize that I want to open up the directory the file is in (and want to do so in the files app rather than the browser). Well, I'll often copy and paste the the file address from the url bar of the browser into the address bar of files.

The address in the url bar of my browser would look something like this:
file:///C:/Users/username/OneDrive/Documents/Work/Some%20Folder/Location/myfile.pdf
From that I'd copy the following segment:
C:/Users/username/OneDrive/Documents/Work/Some%20Folder/Location
The issues is that this isn't actually the correct path. The correct path would be:
C:/Users/username/OneDrive/Documents/Work/Some Folder/Location
with a space instead of %20. Often times I don't even realize there's a space somewhere in the address until I get the "Invalid Item" error message from files. At which point I go through and find each instance %20 and replace them with actual spaces.

I think it would be nice if Files could handle that conversion automatically. If an entered path is invalid and contains those type of strings, maybe it could prompt the user, say this item was invalid, do you want files to convert the valid URL percent encodings and try again?

Some of the encodings are for characters that aren't valid for file / directory names, so those wouldn't be converted, but there are a handful of valid characters with percent encodings. The %20 vs spaces is the main one I come across.

https://en.wikipedia.org/wiki/Percent-encoding

Requirements

Requirements

• This proposal will accomplish the detection of an invalid path entered in the address bar, which will trigger the path correction feature.
• This proposal will accomplish the automatic identification and removal of the file:/// URI prefix from pasted file paths.
• This proposal will accomplish the decoding of standard URL percent-encodings (e.g., %20) found in the path string into their correct character equivalents (e.g., a space).
• This proposal will accomplish the re-validation of the newly corrected path to confirm it points to an accessible location on the file system.
• This proposal will accomplish the presentation of a non-intrusive confirmation prompt to the user, clearly showing the corrected path and asking for permission to proceed.
• This proposal will accomplish the navigation to the corrected path, but only after receiving explicit confirmation from the user.

Files Version

3.9.10.0

Windows Version

Windows 11 Pro Insider Preview - Version 25H2 (OS Build 26200.5670)

Comments

Here are some high-level suggestions for implementing this improvement (they align closely with the requirements):

1. Detect Invalid Path Entry: The file manager should first attempt to resolve the path entered into the address bar. The proposed feature is triggered only if this initial attempt fails to find a valid location.

2. Identify and Sanitize File URI: If the path is invalid, the system should check if the input string is a file URI by looking for the file:/// prefix. If found, this prefix should be stripped from the string.

3. Decode Percent-Encoded Characters: The system must parse the remaining path string and convert all valid URL percent-encodings into their corresponding characters (e.g., converting every %20 to a space).

4. Re-validate the Corrected Path: After sanitizing and decoding the string, the system must re-validate the new, corrected path to confirm that it points to a real directory or file on the user's system.

5. Prompt User for Confirmation: If the corrected path is valid, the system should display a confirmation prompt to the user. The prompt should clearly state that the original path was invalid and offer the corrected path as an alternative (e.g., "Item not found. Did you mean to open C:\...Work\Some Folder?").

6. Navigate Upon Confirmation: The file manager should only navigate to the corrected path if the user explicitly agrees through the confirmation prompt. If the user declines, the address bar should retain the original, uncorrected text for manual editing.

[yaira2]

Thank you for your feedback