Ignored call to 'confirm()'. The document is sandboxed, and the 'allow-modals' keyword is not set

General
1

In our new vanilla ArrayControlRenderer we have the delete button combined with a javascript confirm dialog

image
image1118×345 25.9 KB

This feature runs into a sandbox-problem when running as a VSCode Extension

ArrayControlRenderer.tsx?bd86:116 Ignored call to 'confirm()'. The document is sandboxed, and the 'allow-modals' keyword is not set.

I did not find a way to solve this in the extension code which looks like this:

    webviewPanel.webview.html = `
            <!DOCTYPE html>
            <html lang="en">
                <head>
                    <meta charset="UTF-8">
                    <meta name="viewport" content="width=device-width, height=device-height">
					<meta http-equiv="Content-Security-Policy" content="
                default-src http://*.fontawesome.com  ${webview.cspSource} 'unsafe-inline' 'unsafe-eval';sandbox 'allow-modals';
                ">
				<link href="${codiconsUri}" rel="stylesheet" />
                </head>
                <body>
                    <div id="${clientId}_container" style="height: 100%;"></div>
                    <script src="${webviewScriptSourceUri}"></script>
                </body>
            </html>`;

The problem is, that sandbox params - I think ‘allow-modals’ is what we need here - can’t be set in a meta tag.

Does anybody know about this issue?

My only solution for now would be:

we add a new option to disable the confirm dialog in the UISchema.

2

Hi @rsoika,

We use window.confirm in the ArrayControlRenderer. Luckily window.confirm is not protected, so what you can do is to overwrite it in your webview code with arbitrary behavior, e.g. window.confirm = () => true will just disable it.
Probably nicer would be to delegate to the VS Code API and open a proper VS Code message box with the same question as handed over to window.confirm.

3

Hi @sdirix ,

yes this is working! You are the JavaScript-Mastermind!

My integration web view now looks like this:

....
    webviewPanel.webview.html = `
            <!DOCTYPE html>
            <html lang="en">
                <head>
                    <meta charset="UTF-8">
                    <meta name="viewport" content="width=device-width, height=device-height">
					<meta http-equiv="Content-Security-Policy" content="
                default-src http://*.fontawesome.com  ${webview.cspSource} 'unsafe-inline' 'unsafe-eval';
                ">
				<link href="${codiconsUri}" rel="stylesheet" />
                <!-- disable modal confirm dialog -->
                <script>window.confirm = () => true</script>

                </head>
                <body>
                    <div id="${clientId}_container" style="height: 100%;"></div>
                    <script src="${webviewScriptSourceUri}"></script>
                </body>
            </html>`;
  }

And yes, I agree with you that delegating the origin call to a VSCode message box would be nice. I guess than we should wrap our confirm call into a generic function. Maybe something like

  const confirmDeleteEntry = (message: string): boolean => {
    return confirm(message);
  };

and so it maybe possible to delegate this method to a VSCode messagebox? Should I prepare a pullrequest for this?

===
Ralph

4

Hi @rsoika,

Technically there is no need for a special wrapping. As you can overwrite window.confirm with arbitrary content you can do whatever you like within it.

The problem you are facing however is that the renderer code expects a synchronous call. As the call to the vscode api necessarily involves async messaging, you can’t really call the VS Code API right now. So the change needed in the renderer is to actually await the result of window.confirm, so that it’s possible to hand in async methods. Of course if we do changes there anyway we can also add the wrapping to make it a bit cleaner.

Alternatively to the VS Code API you could implement an own modal in your web view which does not rely on window.confirm and offers a synchronous API.

5

Hi @sdirix
ok, understood. Currently this is no important issue to me - disabling the confirm is fine for me.
If I find some time I will try this out by adding the logic into my web view. I will post my results here.