Repository navigation
Image previewer does not work #3826
Description
OS/Web Information
- Web Browser: Chrome Version 91.0.4472.77 (Official Build) (64-bit) / Version 91.0.864.71 (Official build) (64-bit)
- Local OS: Windows Version 21H1 (19043.1147)
- Remote OS: Red Hat Enterprise Linux Server release 7.9 (Maipo)
- Remote Architecture: amd64 (x86_64)
code-server --version: 3.11.0 4e8cd09
Steps to Reproduce
- Open a png file with the built-in image previewer
Expected
Should show the preview of the image
Actual
The editor shows nothing but just blank
Logs
- The most recent files from ~/.local/share/code-server/coder-logs are empty
- The browser console: no new messages popped up while opening the image
- The browser network tab: This is what appeared while opening the image
Screenshot
while inspecting the body of the editor:
Notes
This issue can be reproduced in VS Code: No
This issue can be reproduced with code-server v3.10.2
Activity
leojonathanoh commentedon Jul 21, 2021
Same issue with a blank webview for images (
.png,jpg, didn't test other images) onv3.11.0, dev tools shows a Content Security Policy error onimg-srcDowngraded to
v3.10.2, and it works (in contrast to OP)jsjoeio commentedon Jul 21, 2021
Hmm...I wonder if something changed with the VSCode upgrade in 3.11. Thanks for the bug report! We'll investigate.
pelletencate commentedon Jul 23, 2021
When I was looking to find out what causes this, I stumbled upon this issue: microsoft/vscode#98768
Given that it was resolved months ago, I can't be sure if this is what's affecting the latest code-server build, but I didn't have time to figure out when this fix was released upstream. Maybe worth looking into.
leojonathanoh commentedon Jul 23, 2021
@pelletencate yep the CSP error I saw was a service worker calling a uri like microsoft/vscode#98768 (comment)
Livven commentedon Aug 3, 2021
Seeing a similar problem here in version 3.10.2. Web views (e.g. markdown preview and also ones from custom extensions) fail to load around 10% of the time.
webview/index.htmliframe includes only thehost.jsscript, but not the innerfake.htmliframe, same as in the screenshot from the original post.jsjoeio commentedon Aug 3, 2021
Thanks for the notes @Livven! I'm seeing similar issues with web views in 3.11. We're currently investigating. More details here: #3883 (reply in thread)
leojonathanoh commentedon Aug 3, 2021
Just wanted to confirm that I did see very intermittent webview errors on
3.10.2as well, even on firefox, like 10% of the time. There were no console errors. My environment was a typicalsystemdinstallation.jsjoeio commentedon Aug 3, 2021
As a temporary workaround, you should be able to use 3.9.3 (when we tested yesterday, we didn't see any issues with webviews there)
Livven commentedon Aug 4, 2021
Thanks for your help @jsjoeio. I tried out the fix in #3883 (reply in thread) but was still able to reproduce the issue. In fact, I am not 100% sure we are talking about the same issue since this one (or at least mine) happens only sporadically.
jsjoeio commentedon Aug 4, 2021
Ah bummer. Thanks for the update @Livven - we'll have to dig into yours separately then. Feel free to open a bug report with repro steps. If we can reproduce yours consistently, we'll have a better chance at figuring out what it could be.
bowdens07 commentedon Aug 6, 2021
The 3.9.3 version did not fix the issue for me either. I've been working on a way to reproduce this bug reliably. It can be done, with a little luck. Here is an alternative to the original method given, although the reproduction rate still seems sporadic.
Steps to Reproduce:
Note- This bug has proven to behave inconsistently across essentially every metric. Individual instances of docker can have varying failure rates. Some docker instances of code-sever seem to never fail, while others fail nearly 25% of the time. This bug can be replicated with almost any extension that uses a webview. I have produced similar results with Excel Viewer by GrapeCity and PlantUML by jebbs, although they are harder to set up on code-sever. The workflow is similar. Their preview functions which also employ WebView (previewing files CSV for Excel, puml for PlantUML) fail in the same manner, also inconsistently. Excel Viewer seemed to fail the most, although it might be random chance as I tested.
I will conclude by getting into the more speculative aspects of my investigation, as sometimes debugging is more intuitive than logical. I have made custom extensions that use webviews and intentionally tried making ridiculous workloads, like an html page that contains 10000 or so .gifs, loops that count to 10 billion, etc. The actual load of the webview did not seem to matter. The failure rate remained just as sporadic. Even more odd, the bug seems to have a higher rate of failure just after the code-server docker image is spun up. If it is left open for 10 minutes or so, failures seem to get more rare,. I have had docker images of code-sever produce preview fail 25% of the time off of startup. That same image, if let idle for a few minutes will not fail anymore, or at some rate like < 1%. Other IDE environments that are not local docker images seem to stay consistent in their fail rate. I have done this testing on multiple different machines. The different machines also seem to go hot and cold producing the bug frequently, or not at all. I will reiterate that it seems like every extension with a webview I try is capable of experiencing this bug. Some are more rare than others, despite my earlier assertion that the load of a given extension does not seem to matter. Markdown All in One will fail at most 2% of the time, while Excel Viewer can fail up to 30% of the time after spinning up a docker image of code-sever and installing the extension. Additionally, limiting browser's core affinity to two cores raises the failure rate, but lowering the affinity to a single core reduces the failure rate. The fluctuations due to the affinity manipulations were at most 10% away from an extension's normal failure rate. When I gave percentages, I tested by opening 50-100 previews for each set of conditions I tried, so the sample size is decent.
If I manage to find a more solid reproduction method, I will be sure to update you.
jsjoeio commentedon Aug 6, 2021
Wow, @bowdens07 - thanks for the thorough investigation notes! That is extremely valuable. @code-asher might have some insight on this since he is a bit more familiar with webviews. We did recently introduce a patch in 3.11.1.
Note: 3.11.1's publish workflow had some issues on npm/homebrew (not yet available) but it is available on Docker if you want to try that.
bowdens07 commentedon Aug 9, 2021
I've checked out 3.11.1 and unfortunately can still reproduce the error through the SVG extension, at about a 2% rate. I would also like to point out that this version cannot open png, gif or jpg files. You'll get this error:
I'm going to open up a new issue for it, because it's an unrelated error to this thread. Additionally, I started messing around with older versions. I found out I can't reproduce the webview error nor the failure to load png, gif, jpg, etc. on version 3.9.0. It's possible this isn't the boundary for the regression, but at the very least I know that version can run without a hitch.
UPDATE: From version 3.9.3 to version 3.10.0 is where the webview failure was added. 3.9.3 works every time, we see png, jpg, gif, extension errors, etc. fail to load the webview in the same manner described in the initial bug report. I suggest investigating the changes between the versions to identify a potential regression
jsjoeio commentedon Aug 9, 2021
Ahh, good to know. Thank for the thorough investigation. I'm surprised the 3.11.1 patch didn't fix it. I wonder what else it could be related to 🤔 At least we know where to start investigating.
code-asher commentedon Aug 10, 2021
It looks like the service worker was introduced in version 1.56.0 of VS Code which is what 3.10.0 uses (3.9.3 uses 1.54).
So I think it's highly likely something about the service worker intercepting requests is the failure point.
bowdens07 commentedon Aug 10, 2021
That could be, although I am strongly inclined to believe that this preview failure never occurs in VS Code locally. I am unfamiliar with VS Code and Code-Sever in general, so maybe there's a interaction or edge case which can only occur on a web environment that I am unaware of. Since the bug reeks so much of a timing error, it's possible that local environments deterministically avoid a bad interleaving while the web IDE cannot. Then again, it could not be a timing error at all. Thank you for the continued support on this.
bowdens07 commentedon Aug 10, 2021
I would also like to add I could have been mistaken. I have not been able to reproduce errors loading markdown and svg files in the previewer in the latest patch. It has, however broken some personal extensions in seemingly different ways. If the error posted about failing to load jpgs, pngs, etc., could be patched this could be more easily confirmed as solved.
code-asher commentedon Aug 12, 2021
bowdens07 commentedon Aug 27, 2021
Do you have any updates on this particular issue? Additionally, are you planning to address this issue by the next release? Thank you.
code-asher commentedon Aug 27, 2021
jsjoeio commentedon Sep 13, 2021
This should be fixed by #4131 which will be included in the 3.12 release (planned to come out this week).
pwwang commentedon Sep 17, 2021
I updated it to 3.12, however, this problem still exists. I does seem to give some informative information in the devtools console:
Tested on both Chrome and Edge and made sure I am not on private/incognito mode.
jsjoeio commentedon Sep 17, 2021
@pwwang based on this error message, it sounds like it's related to your environment. You need service workers enabled. I'd suggest opening a Q and A Discussion and we can help you further!