Improve helper UI handling of reserved URL characters in filenames

[agmap]

Checklist

• I have searched the issue tracker for existing issues.

Description

This is an improvement suggestion for the helper UI input field.

When using the helper UI input field, filenames that contain reserved URL characters can be misinterpreted unless they are percent-encoded.

Example:

ipfs://bafybeifqlwv7k3fmnsluwpugtbnqp4uyvka2r5z7e64r5d2ve4rnvsv2ji/gib-#844.png

When entered into the helper UI input field, this is converted to:

https://bafybeifqlwv7k3fmnsluwpugtbnqp4uyvka2r5z7e64r5d2ve4rnvsv2ji.ipfs.inbrowser.link/gib-#844.png

This does not load the file gib-#844.png, because #844.png is parsed as the URL fragment and the actual path becomes /gib-.

The encoded version works correctly:

ipfs://bafybeifqlwv7k3fmnsluwpugtbnqp4uyvka2r5z7e64r5d2ve4rnvsv2ji/gib-%23844.png

which is converted to:

https://bafybeifqlwv7k3fmnsluwpugtbnqp4uyvka2r5z7e64r5d2ve4rnvsv2ji.ipfs.inbrowser.link/gib-%23844.png

Similar confusion can happen with other reserved characters such as ? and raw/malformed %.

Suggested improvement:

This should only apply to URLs entered into the helper UI input field, where the app still has access to the raw user input before navigation. Normal browser navigation, direct address bar usage, and service-worker/gateway routing should remain standards-compliant.

If the helper UI detects reserved URL characters that may be intended as part of a filename/path, it could ask the user how to interpret them instead of silently accepting the parsed URL.

For example, the UI could show something like:

"Some characters in this input have special meaning in URLs. Should they be treated as part of the filename/path instead?"

Options:

• Keep as URL syntax
  Treat # as a fragment and ? as query parameters.

• Encode as filename/path
  Convert reserved filename/path characters to their percent-encoded form, e.g. # -> %23, ? -> %3F, % -> %25.

For the example above, choosing "Encode as filename/path" would convert:

ipfs://bafybeifqlwv7k3fmnsluwpugtbnqp4uyvka2r5z7e64r5d2ve4rnvsv2ji/gib-#844.png

to:

ipfs://bafybeifqlwv7k3fmnsluwpugtbnqp4uyvka2r5z7e64r5d2ve4rnvsv2ji/gib-%23844.png

This would preserve standards-compliant URL behavior by default, while giving users an explicit way to handle filenames containing reserved URL characters.

[achingbrain]

I appreciate there's a bit of friction for your use case here but I'm not sure about this. If you have reserved characters in the pathname, they have to be escaped, it's just how URLs work.

If a user is entering a CID/IPNS name for a website and it has routing information in the fragment, we'd end up showing the warning for them too, even though it's what they intended which might cause confusion:

ipns://example.com/#some-route

We could probably avoid the confusion by adding something to the 404 page that examines the URL and offers to redirect the user to an escaped version if reserved characters are detected, though it would still be hard to avoid false-positives.