Code-server: Show message when service workers are blocked

[frank-dspeed]

• code-server version:v2
• OS Version: docker image

Description

console output on extension install

Service Workers are not enabled. Webviews will not work properly
Blocked script execution in 'http://0.0.0.0:8080/webview/fake.html?id=extensionEditor' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

Steps to Reproduce

open code-server install remote workspace extension

[sr229]

@code-asher I'm sure we did have service workers enabled for some builds but we have them disabled by default somehow, hence this error.

[code-asher]

Unfortunately service workers will only work over secure origins (localhost/127.0.0.1 or https). You'll need to browse using something other than http://0.0.0.0. :cry:

[code-asher]

Re-opening though because we should have some sort of message explaining what's going on to the user. Also, while some of the webview stuff won't work you should still at least be able to see an extension's data. Are you just trying to view an extension's README or something?

[frank-dspeed]

@code-asher yes i can see the general data like the readme all is working it only hangs on install but then finishes correctly. i will try the https suggestion and i think we should stop then supporting running under http as it makes no sense to run a product in a inconsistent state.

[frank-dspeed]

i think this needs to be documented directly in the readme with high priority

[sr229]

i think this needs to be documented directly in the readme with high priority

I say we hold it for now. I'm opening a line of dialogue within the Chromium developers regarding reserved internal IP CIDRs for service workers and clipboard API.

@code-asher yes i can see the general data like the readme all is working it only hangs on install but then finishes correctly. i will try the https suggestion and i think we should stop then supporting running under http as it makes no sense to run a product in a inconsistent state.

Forcing HTTP/S is not exactly a good state either - this is where some of the complexity Kubernetes had as well because of its strict requirement for HTTP/S (which is understandable).

Again, refer to my response - I'm still opening a line of dialogue with the Chromium team regarding to consider allowing internal CIDRs to use HTTP/S-restricted features.