Reference-style links are not clickable in preview view

[thiskurt]

Describe the bug

When using a reference-style link instead of a wikilink or classic markdown link the link is not accessible in the preview mode, when hovering over the link it reports as 'link to non-existent resource' and clicking on it will not take you to the correct file.

This only applies in the preview window, in the regular editor the link is still accessible as expected.

Small Reproducible Example

No response

Steps to Reproduce the Bug or Issue

1. Create two files
2. Link to the second file from the first file using a reference-style markdown link
3. Show the preview of the page and hover over the link/try to click it to notice it is not accessible that way

Expected behavior

The link in the preview should behave the same as in the editor and the same way wikilinks and classic links behave at the moment.

Screenshots or Videos

No response

Operating System Version

Windows

Visual Studio Code Version

1.73.1

Additional context

No response

[pderaaij]

Hi,

I was looking into this issue to see if I could find a fix. However, when looking at your example I am wondering if we would really want to mix the wikilink syntax with reference-style links. Looking at your example I would wonder if using an alias isn't the appropriate solution here? Like [[Page 2.md|SecondPage]].

Perhaps you can explain more about your use case?

[riccardoferretti]

Both approaches are valid and should be supported. I believe the workaround described can work, but we should nonetheless fix this issue.

The link is not resolving in the same way in preview because in that context we don't have access to the "source" file, therefore we cannot fully resolve the link (given our current approach).

This probably requires a bit of thinking, we have a couple of issues with preview rendering that are due to the context provided and the fact that the work needs to be done synchronously.

[badsketch]

The link is not resolving in the same way in preview because in that context we don't have access to the "source" file, therefore we cannot fully resolve the link (given our current approach).

Any tips on how to get started on this 🙂? I see what you mean by not having access to the source file. Is there a place that's an example of getting the current open file? Was thinking it would have to be passed into preview when its' initialized with the other features in the main extension.activate(), but that part seems to do bootstrapping for all files, rather than the current one. Any advice appreciated!

[riccardoferretti]

The way the extension interacts with the preview is very limited (more limited than when creating one's own webview). The main limitations I have come across are:

• lack of context (e.g. the file the preview is referring to)
• no support for async operations

I haven't found a good solution to these issues.

The path I was considering was to add a script on the webview that would listen for messages from the extension, similar to how things work in the dataviz/graph webview (see dataviz.ts and graph.js). Once we establish a connection between the two, then Foam itself would likely do most of its work through such channel.

Are you interested in looking into this approach and let me know your thoughts? :)

[badsketch]

That sounds interesting! Is preview a webview under the hood? That is, if we're going to make it similar to the foam graph, do we need to create a preview.html that will now store a preview.js and sort of recreate it from scratch? Or would preview.js just have our subscriptions and hooks that will permit context access.

[riccardoferretti]

preview is a webview under the hood, but from what I recall it didn't expose the full API in the same way as a webview created by us. The way we can augment the preview is by injecting a js file in it, see https://code.visualstudio.com/api/extension-guides/markdown-extension#adding-advanced-functionality-with-scripts

I am keen to not recreate it from scratch if possible, as I fear that even reaching feature parity would be painful, and I have resisted also relying upon other preview extensions (such this ) as I think it's better to keep as close as possible to the default setup.

[Alecton4]

Now the problem is even worse. I'm not sure whether it's caused by VSCode or FOAM, although extension bisect indicates it's caused by FOAM.

When clicking the reference-style links in preview view, the whole editor view will be shifted up. Closing the "file not found" page can restore it.

Compare the two pics below:

[pderaaij]

I started to play around with the advanced scripts. It requires a bit of work. The idea is that the advanced script is a bundled file. So, in my test, I've added a webpack bundle to create an extension preview script. That works quite nice, but now I ran into a different issue. As the script is an isolated environment, you don't have access to the workspace. The event is only a notification and doesn't hold any additional information.

In the context of embedding notes, this is quite challenging, as we need access to the workspace to find and load files. I am not sure how to handle this. @riccardoferretti any thoughts?

[riccardoferretti]

As the script is an isolated environment, you don't have access to the workspace

That sounds about right

The event is only a notification and doesn't hold any additional information.

That I am not sure I understand. The way I was thinking about it is that once you have a channel open, you can send information between the VS Code instance and the preview using . But maybe I am missing something? ... I just answered myself by doing a bit more research on the issue, and I came across this: https://github.com/microsoft/vscode/issues/174080 so clearly by design there is very limited access to the markdown preview webview (I am not sure I understand why).

Basically the approach I had in mind can't work.

In order to move forward with the web extension I feel we need to go for one of these:

• VS Code makes the extensions to markdown-it async (probably not trivial)
• VS Code provides a channel between main thread and the preview webview (this is what has been talked about in https://github.com/microsoft/vscode/issues/174080)
• We find a way around the async readFile function
• We find a way to disable embed when Foam is run as a Web Extension

Anything else I am missing?

Feel free to also share a draft PR with your approach, I am curious to take a look.

[pderaaij]

Hi,

It has been a while since I had time to look at this. Unfortunately, there has not been a reply on the VS Code issue as well.

The best option for now is to disable embed in the web extension. Need to figure out how exactly, but will be doable. What do you think @riccardoferretti ?

[riccardoferretti]

Yes I think that is the sensible option at this point. And I think it's worth it because:

• it doesn't impact current users and use cases
• it still provides a better experience for web users (as today such experience is "no foam", and after this change it will be "yes foam, except embeds")

Feel free to suggest the technical approach/implementation, thanks :)