fix(desktop): resolve local link paths without decoding the document folder (#4749) - #5506

Closes #4749. Supersedes #4773 (closed — it patched the pre-#5298 shape of this code and covered only one of the three triggers).

Summary

resolveLocalLinkTarget() joined the document folder with the link target and then ran decodeURIComponent() over the joined string, unguarded. That is wrong in two independent ways, and together they made Ctrl/Cmd-clicking a perfectly ordinary local link throw URIError: URI malformed out of the mt::format-link-click handler.

1. The document folder was being decoded. The link target is URL-encoded text taken from the document, but dirname (window.DIRNAME) is a raw filesystem path that may legally contain %. Decoding the joined string therefore misreads the document's own folder name:

This is the mirror image of the renderer-side asymmetry that encodeDirnameForUrl() already documents (#5212 / #5302). The first commit decodes the target alone and joins the raw dirname. isAbsolute keeps testing the encoded target, so a %2F cannot turn a relative link into an absolute one.

2. A target that is not valid percent-encoding threw. % is a legal filename character, so the second commit falls back to the target as written instead of rejecting the click — the same fallback the renderer already applies to anchors in SCROLL_TO_ANCHOR:

• [broken](bad%zz.md)
• [bare](%.md)
• [partial](%E0%A4%A.md)
• [frag](other.md#100%) — toPathname() runs before the # split, so an invalid escape anywhere in the destination was enough to throw. fix: #4749 handle malformed percent-encoded local links #4773 wrapped the whole link instead, which baked #100% into the path so the file never opened. With the guard inside toPathname() the case resolves correctly: the literal path does not exist, the # split runs, and other.md opens with 100% handed to the renderer, which tolerates an undecodable anchor.

Note that since #5298 made this handler async, the throw surfaced as an unhandledRejection (logged only in main/index.ts) rather than the uncaughtException error dialog described in #4749 — so on develop the symptom is currently a click that does nothing at all.

Type of change

• Bug fix (non-breaking, fixes an issue)
• New feature (non-breaking, adds functionality)
• Breaking change (causes existing functionality to change)
• Documentation update

Test plan

• New tests added

Seven regression cases in packages/desktop/test/unit/specs/local-link-target.spec.ts, covering all four destinations listed in #4749 plus the three folder-name cases from the table above. Each was watched failing against develop first: the folder cases fail with URIError at filesystem/index.ts:41 (and my%20docs/ fails on the wrong resolved path), the malformed-target cases fail with URIError.

pnpm -C packages/desktop exec vitest run test/unit/specs/local-link-target.spec.ts   # 12 passed
pnpm run test        # 65 files, 875 tests passed
pnpm run lint        # clean
pnpm run typecheck   # clean

Notes for reviewers

Deliberately out of scope, both pre-existing and worth separate issues if wanted:

• A click on a local target that does not exist remains a silent no-op (isMarkdownFile() requires the file to exist, so it falls through to shell.openPath() whose rejected promise is discarded). [Bug] Malformed percent-encoded local link throws an unhandled URIError in the main process #4749 asks for a "cannot open location" prompt; that would change behaviour for every broken local link, not just malformed escapes, so it is not bundled here.
• FormatLinkPayload.dirname is optional in main/menu/actions/file.ts while ipc.ts declares it required.

Credit to @jianongHe, whose report in #4749 and analysis in #4773 established the right fallback semantics; the reproduction cases listed there are in the spec.

🤖 Generated with Claude Code