Image previewer does not work

[pwwang]

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

1. 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

1. The most recent files from ~/.local/share/code-server/coder-logs are empty
2. The browser console: no new messages popped up while opening the image
3. 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

[leojonathanoh]

Same issue with a blank webview for images (.png, jpg, didn't test other images) on v3.11.0, dev tools shows a Content Security Policy error on img-src

Downgraded to v3.10.2, and it works (in contrast to OP)

[jsjoeio]

Hmm...I wonder if something changed with the VSCode upgrade in 3.11. Thanks for the bug report! We'll investigate.

[pelletencate]

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]

@pelletencate yep the CSP error I saw was a service worker calling a uri like microsoft/vscode#98768 (comment)

[Livven]

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.

• No console errors, instead the webview/index.html iframe includes only the host.js script, but not the inner fake.html iframe, same as in the screenshot from the original post.
• This is happening using the Docker image on localhost, so should rule out weird network issues.
• Reproducible in Chrome, Edge and Firefox.

[jsjoeio]

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]

Just wanted to confirm that I did see very intermittent webview errors on 3.10.2 as well, even on firefox, like 10% of the time. There were no console errors. My environment was a typical systemd installation.

[jsjoeio]

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]

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]

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]

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:

1. Open some instance of code-sever in firefox/chrome/edge hosted by docker on localhost (linuxsever/code-sever or codercom/code-sever both work)
2. Download the SVG extension. (v0.1.6 by jock)
3. Upload any valid SVG file into the code-sever project explorer
4. Open the SVG file
5. Click the previewer button to open a preview of the svg file. It should reproduce the bug relatively frequently (5-25% of the time).
   
   
   

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]

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]

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]

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

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]

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]

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]

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]

Local VS Code doesn't use service workers for the web view I believe, instead they use some API natively provided by Electron. So service workers are a web-only thing for VS Code. I've also been seeing this frequently (using VS Code's `webview-sample` extension) although I haven't tested on the latest patch. A timing issue seems like a good possibility. I think with some logging around this we could narrow it down pretty quickly.

[bowdens07]

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]

No updates yet; currently we have this in the "On Deck" milestone so it is a candidate for being worked on but not yet assigned to a release. We are making some architectural changes to code-server so it might make sense to wait until that is completed and we have updated to the latest VS Code before tackling this because we may end up addressing some instability issue in doing so.

[jsjoeio]

This should be fixed by #4131 which will be included in the 3.12 release (planned to come out this week).

[pwwang]

I updated it to 3.12, however, this problem still exists. I does seem to give some informative information in the devtools console:

Uncaught TypeError: Cannot read properties of undefined (reading 'addEventListener')
    at main.js:399
main.js:203 Uncaught (in promise) Error: Service Workers are not enabled. Webviews will not work. Try disabling private/incognito mode.
    at main.js:203
    at new Promise (<anonymous>)
    at main.js:201

Tested on both Chrome and Edge and made sure I am not on private/incognito mode.

[jsjoeio]

main.js:203 Uncaught (in promise) Error: Service Workers are not enabled.

@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!