Open Atrejoe opened 4 years ago
There could be an 'Show Images' option in the preview pane, just like it is done by Gmail.
We treat the MD file the same (in theory) as the HTML file. HTML blocks scripts / images so we do the same. If there is a scenario we did incorrectly, please make us aware but right now we don't want to allow a file to arbitrarily load a random script.
scenario i'm primarily thinking of is the img is local versus loaded off the internet.
@Atrejoe can you email me? love to sync on all your MD things here. crutkas@microsoft.com
Right now we're mimicing the pattern for HTML files. we'll look into this a bit more
I also would like to request the ability to show local images. It would be very useful.
Similarly to #3713 I misunderstood "Open this item to view pictures", to mean click the header. You could change the wording to "Open the file to view pictures." (While you work on the image support.)
We treat the MD file the same (in theory) as the HTML file. HTML blocks scripts / images so we do the same. If there is a scenario we did incorrectly, please make us aware but right now we don't want to allow a file to arbitrarily load a random script.
But the big difference is that it allows you to override and view. I am using HelpNDoc to build my help system as MD files on my PC so I would like to view them properly.
At the moment I use VS Code or VS with extension.
I found this github issue after also looking for a way to allow images to be displayed in the markdown preview panel. I, too, would find it helpful if the user could enable image previews, particularly for images stored in local files.
I appreciate the developers' security concerns, but when the png/jpg/tiff/etc. image is coming from the local file system, do the same tracking/security risks still exist? Obviously the security risks do exist for locally-served SVG files, so perhaps things could be changed so that the preview shows non-SVG images, with the current warning shown only when the image is SVG? In other words, change things so that when the image is a locally-served png/jpg/tiff image, images are shown, and otherwise, the warning is shown.
@crutkas , I experienced the same journey as @mhucka. Support having some method of resolving local image files in the preview.
I concur with previous posters. Not having some way to view the images in our markdown makes this feature worthless, and it might as well be removed from the product.
I don't mean to sound harsh, and I do understand the security reasons. I even concur it should be off by default.
But how about giving your users credit for having the intelligence to decide when we want to accept the risk involved? If I'm looking at a folder of my own documentation, I want to be able to preview that without having to open up more apps. File Explorer just feels like the right way to implement this, just like we are able to preview images, DOCX files, etc.
14 months later I'll comment again.
To prevent tracking my email client has a "click to enable" option for any images that are included in emails I receive. If I don't want to load them while reading an email, I do nothing & enjoy the default blocking that is provided. If I do want the images and am willing to accept that I may be tracked, I click that option. If my email client didn't allow me to ever view the images, I simply wouldn't (and couldn't) use it.
That's equivalent to the state of this tool here and sadly why I cannot use it. To me, it makes no sense to not allow this as an option. I think anybody using this should be treated as capable of making an informed opt-in decision to load images. If for some reason someone has no idea why they are using this tool or what files they are loading with it, well the default is protecting these poor lost souls. For the rest of us, what I assume would be nearly the entire potential userbase, we could actually make intentional use of it.
Its now april 2022 and still no solution for this. This is disapointing, I am going to look for another solution and uninsall powertoys. Very disapointing to say the least.
This is super frustrating. More than two years later, there is still no option to preview images. Give us an option to enable this.
It would be great if images with local (relative) paths were shown by default (or via an option), However, non-SVG in-line images using the _data URI scheme_ could always be rendered, since they're embedded in the markdown file itself and shouldn't be able to make remote requests.
For example, this GIF:
![Embedded Image](data:image/gif;base64,R0lGODlhJQAlAIAAAP///wAAACH/C1hNUCBEYXRhWE1QPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNy4xLWMwMDAgNzkuOWNjYzRkZTkzLCAyMDIyLzAzLzE0LTE0OjA3OjIyICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgMjMuMyAoV2luZG93cykiIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6OUYzMTU0QjFFOTI2MTFFQ0I3NjRERTIxQ0RBNzkzMkIiIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6OUYzMTU0QjJFOTI2MTFFQ0I3NjRERTIxQ0RBNzkzMkIiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDo5RjMxNTRBRkU5MjYxMUVDQjc2NERFMjFDREE3OTMyQiIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDo5RjMxNTRCMEU5MjYxMUVDQjc2NERFMjFDREE3OTMyQiIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk4+Lh4N/e3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayrqqmop6alpKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNycXBvbm1sa2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5ODc2NTQzMjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEAACH5BAAAAAAALAAAAAAlACUAAALZhI+py+3vgpwBUDNt1ZhKtB1bxo2dlYRoVn3XKraaLM5re9HYrfPoX5ORcD0VrOMS1kAgj/IJI74iSCTLyBAOSzstDghMSlO80GcZvUXNtuLPfDZZR9hdugS3uzjN1Flth8fXFaNCp2czeCKYuHZnZLiXVOZYt6f4NcNW5yf5JgdGwvR28nSYF5R5aeKJGoO4SWT1WjgH98JGyGRYe9W54KWpyucBsfs1FgYqLLkM24jWdfXHFUjGspjqJXpsik3nCeaTl/l5GHpdGxYN7PQqRkNuPE9fb29QAAA7)
With regards to images with remote sources, it would be great to have a "click to show images" link in the security banner if the default behavior is not to trust them. I'm using the preview pane so that I don't have to open the files to view contents, and it would be so much easier to just see them in the preview.
Is this still on the schedule? Or the future had been completely dropped for the plans?
@Drakemoor we never had it on the schedule or committed to it. Big work item for us would be to figure out why the file explorer team intentionally did not load images.
Still waiting for this, might look for an alternative to PowerToys. Feel free to @ me and suggest a better tool.
@crutkas any update on this ? wasn't the security warning in explorer meant to avoid leaking infos to the server hosting images ? it makes no sense to block local images embedded inside local documents.
Is "show local images in HTML and MD" on the roadmap?
Please add this feature.
If we are using Webview2 now is this not the way we can load local images in previews?
Its now april 2022 and still no solution for this. It is very easy to add a selection I think. Why not do it?
@mhucka said,
In other words, change things so that when the image is a locally-served png/jpg/tiff image, images are shown, and otherwise, the warning is shown.
I'd also like to add that newer webp
and avif
images formats should be supported along with the older gif
, jpg
, png
, and tiff
formats.
I just discovered there's one way to get non-remote images to appear by default in the preview, but it requires the image data to be embedded using the data URI scheme along with actual HTML to render the image, not standard image markdown.
❌Basic local images will fail to render with both markdown and HTML.
![running-man](running-man.png)
<img src="running-man.png" alt="running-man" />
❌An embedded image will fail when markdown is used:
![running-man](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAwAAAAMAQAAAAB+DmFKAAAAJ0lEQVR42mNgYGBgZGBgbgAhdgYG6QYGswQGNgYQ27aBgbGBgbEBADnMBAzjG5+6AAAAAElFTkSuQmCC)
✔️However, the embedded image seems to work when used along with the HTML image tag:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAwAAAAMAQAAAAB+DmFKAAAAJ0lEQVR42mNgYGBgZGBgbgAhdgYG6QYGswQGNgYQ27aBgbGBgbEBADnMBAzjG5+6AAAAAElFTkSuQmCC" alt="running-man" />
Now logically, if the preview can already render (by default) embedded images using the IMG tag, there should be NO reason to prevent markdown from performing the same task.
It should be said that embedding image data in markdown files will ultimately make the text files cumbersome and more difficult to edit, and it really seems to conflict with the spirit of markdown as a very readable syntax. Having BASE64 data filling up most of the text file just looks really bad. 🤢🤮
Ideally, local images should render by default using pure markdown, so I'm still hoping we'll have a real solution to this issue in the very near future.
@crutkas I think this issue is long overdue to be addressed. It's been 4 years since it was initially opened and talked about, can we please have an update?
Has there been any consideration about this request? It would be very helpful to be able to see local images in the markdown preview using standard markdown syntax. Since they're local images references, there should be no security risk when accessing them.
One other way to get images to render at this time is to embed a <STYLE>
block with custom CSS in the document (such as at the bottom) and specify a background-image
property that references a data-URI image.
<style>
pre {
background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAwAAAAMAQAAAAB+DmFKAAAAJ0lEQVR42mNgYGBgZGBgbgAhdgYG6QYGswQGNgYQ27aBgbGBgbEBADnMBAzjG5+6AAAAAElFTkSuQmCC);
}
</style>
The above renders the background image for all <PRE>
blocks in the document, however no image is rendered when local or external image references are used instead. Only data-URI images work in this case.
It goes without saying that this workaround will be unnecessary in the future if/when the viewer directly supports the rendering of local images. 🙏
Iit would be nice if the images referred to in Markdown files could be shown. This may be a security issue though.