Greptile Summary

This PR replaces the third-party url-parse library with a thin URLParse shim (src/utils/urlParse.js) that wraps the native WHATWG URL constructor and catches TypeError to return safe empty-string defaults, then updates all three call sites to use it.

• The new shim correctly handles malformed/missing-scheme URLs that previously relied on url-parse's lenient parsing, resolving the unguarded new URL() risks flagged in prior reviews.
• However, all three call sites (remoteStorage.js, Url.js, fileBrowser.js) still call decodeURIComponent() on values returned by searchParams.get() or Object.fromEntries(searchParams), both of which already return percent-decoded strings per the WHATWG spec — a double-decode that throws URIError: URI malformed whenever a stored path or passphrase contains a literal % after the first decode.

Confidence Score: 3/5

The migration to the WHATWG URL API is structurally sound, but the double-decode pattern left in all three call sites will crash edit/delete flows for any user whose key-file path or passphrase contains a % character after the initial decode.

The URLParse shim and the removal of url-parse are clean. The issue is that URLSearchParams.get() and Object.fromEntries(searchParams) both return already-decoded strings, so the surviving decodeURIComponent() calls on those values are a double-decode present in all three changed files. For most values this is a no-op, but for any key-file path or passphrase that was stored with a percent-encoded % (i.e. %25), the first decode produces a bare % and the second call throws URIError: URI malformed, breaking the edit flow in remoteStorage.js, the SFTP decode path in Url.js, and the key-file cleanup in fileBrowser.js.

src/lib/remoteStorage.js, src/utils/Url.js, and src/pages/fileBrowser/fileBrowser.js all retain redundant decodeURIComponent calls on searchParams-sourced values that should be removed.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Input URL string] --> B{URLParse shim}
    B -->|valid URL| C[new URL - WHATWG]
    B -->|throws TypeError| D[Fallback object\nempty strings + empty searchParams]
    C --> E[URL object\nusername/password: percent-encoded\nsearchParams.get: already decoded]
    D --> E
    E --> F{Field type}
    F -->|username / password| G[decodeURIComponent OK\nneeded - URL spec keeps these encoded]
    F -->|searchParams.get values\nsecurity, mode, keyFile, passPhrase| H[decodeURIComponent WRONG\nalready decoded - double-decode\nthrows URIError if value contains bare %]

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Input URL string] --> B{URLParse shim}
    B -->|valid URL| C[new URL - WHATWG]
    B -->|throws TypeError| D[Fallback object\nempty strings + empty searchParams]
    C --> E[URL object\nusername/password: percent-encoded\nsearchParams.get: already decoded]
    D --> E
    E --> F{Field type}
    F -->|username / password| G[decodeURIComponent OK\nneeded - URL spec keeps these encoded]
    F -->|searchParams.get values\nsecurity, mode, keyFile, passPhrase| H[decodeURIComponent WRONG\nalready decoded - double-decode\nthrows URIError if value contains bare %]

_{Reviews (3): Last reviewed commit: "chore: use URLParse" | Re-trigger Greptile}

WHATWG URL will throws on invalid input but url-parse not, maybe We should add exception handler?

WHATWG URL will throws on invalid input but url-parse not, maybe We should add exception handler?

Yes

@greptile review again

@greptile review again

@RohitKushvaha01 what about the double-decode problem? Because the query values on original url-parse return value are also decoded.