Relative links with '..' don't resolve correctly when clicked in preview

[gpolitis]

Description

When clicking a relative markdown link that uses .. to navigate to a parent directory, the link fails to open the file.

For example, given this file structure:

project/
├── docs/
│   └── notes.md       ← editing this file
└── assets/
    └── diagram.pdf

A link in notes.md like [Diagram](../assets/diagram.pdf) should open project/assets/diagram.pdf, but it fails silently.

Links within the same directory (e.g., [Other](other.md)) work correctly.

Root Cause

In EditorViewController+Delegate.swift (lines 16-42), the createWebViewWith delegate handles link clicks from the WKWebView:

1. The preview WebView has baseURL = http://localhost/
2. A relative link like ../assets/diagram.pdf is resolved by WKWebView against http://localhost/, producing http://localhost/assets/diagram.pdf (the .. is consumed since you can't go above the URL root)
3. The string replacement then swaps http://localhost/ with document.baseURL (e.g., file:///project/docs/)
4. Result: file:///project/docs/assets/diagram.pdf — which is wrong. It should be file:///project/assets/diagram.pdf

The .. component is lost during step 2 because HTTP URL resolution normalizes it away before the string substitution in step 3 can preserve it.

Suggested Fix

Resolve the relative path against document.baseURL directly instead of relying on string replacement of the WKWebView's localhost URL. For example:

func webView(_ webView: WKWebView, createWebViewWith configuration: WKWebViewConfiguration, for navigationAction: WKNavigationAction, windowFeatures: WKWindowFeatures) -> WKWebView? {
    guard let url = navigationAction.request.url else {
        return nil
    }

    let resolvedURL: URL? = {
        // If it already has a file scheme or other real scheme, use directly
        if url.scheme != "http" || url.host != "localhost" {
            return url
        }
        // Resolve the original relative path against the document's base URL
        guard let baseURL = document?.baseURL else { return nil }
        let relativePath = url.path.removingPercentEncoding ?? url.path
        return baseURL.appending(path: relativePath).standardized
    }()

    if let resolvedURL {
        NSWorkspace.shared.openOrReveal(url: resolvedURL)
    }

    return nil
}

The key addition is .standardized which resolves .. components in the path.

Workaround

Create a symlink in the subdirectory pointing to the parent, allowing forward-only relative paths that avoid ...

[cyanzhong]

Thanks for reporting. I am wondering is this report generated entirely using AI?

[gpolitis]

Good guess :)

[cyanzhong]

Are we talking about cmd-clicking links or clicking links in preview mode with this extension: https://github.com/MarkEdit-app/MarkEdit-preview?

[gpolitis]

This is about clicking links in preview mode. Although I haven't tried what happens in the editor mode, I suspect the same code path is executed so the same issue occurs, I could be wrong though. I opened the issue in this repo because AI determined the issue is in this repo, sorry if it's the wrong place.

[cyanzhong]

It's fine to open issues here, but the root cause provided by AI is wrong.

The method to reveal a local file natively supports relative paths.

The root cause is that in preview extension, ".." isn't honored because it is going to escape the website root, may need extra work there instead.

[gpolitis]

I see, thank you for taking a closer look so quickly and for identifying the correct root cause. One cannot and must not trust AI too much..

[cyanzhong]

Build generated by this change works for me: https://github.com/MarkEdit-app/MarkEdit-preview/pull/86/changes

markedit-preview.js

Can you also try it out?

[gpolitis]

Thank you for the quick fix! I tested it and it works for files without spaces in the path. For files with spaces (percent-encoded as %20), the link doesn't open yet. I left a suggestion on the PR: MarkEdit-app/MarkEdit-preview#86

[cyanzhong]

Thanks. I will take a look today.

If percent encoding is a concern here, it feels like we should either extending the fix to all local paths (currently only for ../）, or decoding in native, or both.

[gpolitis]

Oooh, that makes sense. I didn't realize this was a broader issue, but the CommonMark spec requires that link destinations (without angle brackets) cannot contain spaces, so percent-encoding (%20) is the only valid option for paths with spaces. I tried using plain spaces in the link URL and markdown-it doesn't even parse it as a link.

Happy to test another build when you have one ready!

[gpolitis]

Just to clarify, percent-encoded relative paths like some%20folder/file.pdf (without ../) work fine through the existing link handling. The percent-encoding issue is specific to the new ../ handler, since joinPaths + openFile constructs a raw file path rather than going through the URL system that normally handles decoding.

I also tested absolute paths (e.g. [file](/tmp/toto.txt)) and those don't work either. Probably the same class of issue where the WKWebView resolves against http://localhost/ and the string replacement produces an incorrect path. Might be worth handling those too if you're extending the fix to all local paths.

[cyanzhong]

I don't think we should aim for absolute paths. In the end, we might not even know if a path is absolute or relative. Right now, paths are relative to the file we're editing, unless we use a scheme like file://.

[gpolitis]

Thanks for the quick turnaround on this! Makes sense to keep the scope to relative paths for now. I might be misunderstanding, but wouldn't paths starting with / always be absolute on macOS? Also I tested file:// scheme links (e.g. [file](file:///tmp/toto.txt)) and markdown-it doesn't seem to render them as links, so that might not be an option.