Image hover preview shows empty hover window; image never renders (VS Code and Positron)

Bug description

Hovering over a Markdown image reference in a .qmd document (e.g. ![](images/plot.png)) opens a small hover popup, but the image itself never renders. The popup is empty:

"Follow link" works correctly, but there is no image hover. Reproduces in both VS Code and Positron with the Quarto extension.

Steps to reproduce

1. Create a .qmd document containing an image reference to an existing local file, e.g. ![](images/plot.png).
2. Hover over the image path/reference.
3. Observe: a hover window appears, but no image is displayed.
4. Following the link works correctly.

Expected behavior

The hover popup shows a preview of the image.

Actual behavior

A hover window appears, but the image content never loads.

Investigation so far

Image hover is implemented client-side in the extension (apps/vscode/src/providers/hover-image.ts), invoked from the hover middleware in apps/vscode/src/lsp/client.ts. The implementation resolves the local file path correctly, but builds the hover content as raw HTML with a bare filesystem path as the image source:

​ts const content = new MarkdownString( `<img src="${imagePath}" ${widthAttrib}/>` ); content.supportHtml = true; content.isTrusted = true; ​

supportHtml and isTrusted are set, but VS Code's hover Markdown renderer sanitizes HTML and only loads image sources with well-known URI schemes (http(s):, data:, etc.). A bare OS path like /Users/.../plot.png (or C:\... on Windows) is not resolvable, so the popup renders (hence the visible empty hover window) but the image never loads. Note that Uri.file(imagePath) is never used, so even a file:// URI isn't produced.

This is corroborated by the history of this feature. The original server-side implementation (apps/lsp/src/service/providers/hover/hover-image.ts) embedded the image as a base64 data: URI (![](data:image/png;base64,...)), a scheme the hover renderer can load, but it was disabled because of a hover content size cap (~75k), per the comment in apps/lsp/src/service/providers/hover/hover.ts. The client-side replacement avoided the size cap by referencing the file directly, but in doing so appears to have lost the ability for the image to render at all.

Additional related issues noticed while investigating

• There is no handling of http(s):// image URLs. Remote images silently produce no hover at all (the path is joined onto the document directory, fails fs.existsSync, and returns null).
• Non-PNG images get no width hint (cosmetic; imageWidth() only handles .png).
• Workspace-rooted paths only ever resolve against the first workspace folder.

Possible fix directions

• Inline the image as a data: URI (as the old server-side code did), with size guarding or downscaling to stay under the hover content cap.
• Convert the path to a scheme the hover sanitizer will load (verify whether file:// via Uri.file().toString() works in current VS Code).
• Document and confirm the intended behavior and supported image types.
• Run away from home and live in the woods

Start with apps/vscode/src/providers/hover-image.ts and the hover middleware in apps/vscode/src/lsp/client.ts to trace how the local image path becomes hover content. Compare this with the former implementation in apps/lsp/src/service/providers/hover/hover-image.ts and the size-cap context in hover.ts. Done means a local image reliably renders in the hover popup in VS Code and Positron, with the supported image and URL behavior established.