Bug description
Hovering over a Markdown image reference in a .qmd document (e.g. ) 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
- Create a
.qmd document containing an image reference to an existing local file, e.g. .
- Hover over the image path/reference.
- Observe: a hover window appears, but no image is displayed.
- 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 (), 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
Bug description
Hovering over a Markdown image reference in a
.qmddocument (e.g.) 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
.qmddocument containing an image reference to an existing local file, e.g..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 inapps/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; supportHtmlandisTrustedare 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(orC:\...on Windows) is not resolvable, so the popup renders (hence the visible empty hover window) but the image never loads. Note thatUri.file(imagePath)is never used, so even afile://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 base64data:URI (), a scheme the hover renderer can load, but it was disabled because of a hover content size cap (~75k), per the comment inapps/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
http(s)://image URLs. Remote images silently produce no hover at all (the path is joined onto the document directory, failsfs.existsSync, and returnsnull).imageWidth()only handles.png).Possible fix directions
data:URI (as the old server-side code did), with size guarding or downscaling to stay under the hover content cap.file://viaUri.file().toString()works in current VS Code).