You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Editor hover: markdown links should use their own custom scheme #119786
comment out the line that reads Image preview is currently not supported
Run
open a markdown document with a reference to a PNG in the workspace
retype it as memo notation (e.g. [[images/1_54/macOS-universal-download.png]])
hover over it
=> 🐛 it looks like the resulting image tag uses file protocol and not vscode-file protocol:
We need to make sure to use the FileAccess utility to properly convert to a URL that the browser can handle.
Slightly related: Robo (@deepak1556) expressed some interest that the generated HTML from markdown uses a custom scheme so that we can distinguish markdown content from our core content. I had to push a34297a now as a workaround.
To clarify, I am proposing to keep vscode-file only deal with resources for the core, we create a separate scheme (ex: vscode-hover) to load resources for the hover html. That way we can keep the restrictions around vscode-file stricter and additionally there is no added cost to having multiple schemes in an app, offering cleaner separation for resource loading.
changed the title [-]Editor hover: markdown links are `file://` based even when `vscode-file` is enabled[/-][+]Editor hover: markdown links should use their own custom scheme[/+]on Mar 25, 2021
As such, we probably just take the contents as is and rely on the fact that we currently still support to embedd file URIs for rendering.
But going forward this will not be possible anymore, because once we set our origin to vscode-file://, Chrome disallows any file:// URIs to be loaded.
I think we almost have to detect absolute URIs that are file based and rewrite them to a custom scheme like Deepak suggests to resolve this going forward.
We already use the FileAccess-util for uris that have been transformed and it should be easy to use them for all, tho I am unsure how a unified scheme can be achieved because some need the special "this is from a remote" scheme already
Mistakenly checked in a revert of the original fix while fixing another bug. Should be fixed again now. Just tested with Flutter and confirmed the icons show up
Activity
deepak1556 commentedon Mar 24, 2021
To clarify, I am proposing to keep
vscode-fileonly deal with resources for the core, we create a separate scheme (ex:vscode-hover) to load resources for the hover html. That way we can keep the restrictions aroundvscode-filestricter and additionally there is no added cost to having multiple schemes in an app, offering cleaner separation for resource loading.[-]Editor hover: markdown links are `file://` based even when `vscode-file` is enabled[/-][+]Editor hover: markdown links should use their own custom scheme[/+]bpasero commentedon Mar 25, 2021
After looking a bit closer into what the extension does, I realised that the extension is actually returning
file://URIs as hover contents from here:https://github.com/svsool/vscode-memo/blob/5dc4fe035b7c4474d29c6cd24afd33f5e13a1a6e/src/features/ReferenceHoverProvider.ts#L56
As such, we probably just take the contents as is and rely on the fact that we currently still support to embedd
fileURIs for rendering.But going forward this will not be possible anymore, because once we set our origin to
vscode-file://, Chrome disallows anyfile://URIs to be loaded.I think we almost have to detect absolute URIs that are
filebased and rewrite them to a custom scheme like Deepak suggests to resolve this going forward.jrieken commentedon Mar 25, 2021
We already use the FileAccess-util for uris that have been transformed and it should be easy to use them for all, tho I am unsure how a unified scheme can be achieved because some need the special "this is from a remote" scheme already
jrieken commentedon Mar 25, 2021
// roblourens unsure what the snippet below is for but it will be broken once we don't use the file-scheme anymore
vscode/src/vs/base/browser/markdownRenderer.ts
Lines 105 to 108 in 5539322
22 remaining items
LuquinhasSG commentedon Aug 25, 2021
I migrated from Vs Code to Vs Code Insiders in build 1.60 with all extensions updated and the problem remains.
jrieken commentedon Aug 26, 2021
This has likely regressed with 1888070 (which undoes the original fix). Matt Bierner (@mjbvz) I am leaving this up to you since you did the inital fix
mjbvz commentedon Aug 26, 2021
Mistakenly checked in a revert of the original fix while fixing another bug. Should be fixed again now. Just tested with Flutter and confirmed the icons show up
Make sure we always try rewriting domUris in markdown strings
Fix microsoft#119786