Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refresh Images In Markdown Preview On Change #114083
Refresh Images In Markdown Preview On Change #114083
Changes from 2 commits
6ab95dc
5fab4f9
d42736a
75d7e27
3fbd303
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you are using the query string make sure we don't used cached image. I wonder if VS Code should be doing this automatically though by looking at etags or similar for the resource?
Have you debugged to see why the images are being cached in the first place? Are
vscode-webview-resource
request perhaps not setting the correct cache headers?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A very good idea. I changed the approach and got rid of the cache keys. Instead, responses to
vscode-webview-resource
requests have an etag and a cache-control header now. Also,if-none-match
is implemented.Basically it is a pull approach now - on every possible change, all resources with an etag are re-requested. However, responses are cached.
Before it was a push approach - only if an image actually changed, it got re-requested.
The advantages of this vs cache keys are:
The disadvantages are:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This import will fail in browsers. I think you can instead what I do here:
vscode/extensions/simple-browser/src/extension.ts
Line 10 in 6cceb4e
This will let you use the globally defined
URL
object that ships in both browsers and nodeThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I changed that. Are the tests in
markdown-language-features
run in both node and browser environments?Edit: I don't think so, otherwise CI would have detected that this import will crash.
I used to think even when VS Code runs in the browser, extensions have to be run inside a node environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've had lots of problems in the past around encoding/decoding of special characters in uris. Make sure to add tests for cases where the uri has percent encoded characters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some tests with percent characters. I don't know the spec though and what pitfalls there are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may be on a virtual file system, so we probably should not restrict this to 'file' uris. Instead you can use
isWritableFilesystem
to see if a given scheme is known to VS CodeThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But
createFileSystemWatcher
seems to work on file paths only, doesn't it?I generalized the function, but changed the consumer to this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, we may be on a virtual file system so generally we can't assume that we are on a
file://
.I think it's fine if you want to restrict the first version of the feature to
file
uris, but if that's the case, make sure the function names make this clearThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is now obsolete.
Anyways, as long as the file system watcher does not support virtual file systems (i.e. accepts
vscode.Uri
s instead of the file path based glob), thefile://
protocol is the only one that can be supported afaik.