Webview Inconsistency in acquireVsCodeApi injection behavior.

[dineug]

Bug Description:

Webview Inconsistency in acquireVsCodeApi injection behavior. Consistency in behavior for compatibility.

// vscode
globalThis.acquireVsCodeApi = (function() {
    // ...
})();
delete window.parent;
delete window.top;
delete window.frameElement;

// theia
const acquireVsCodeApi = (function() {
    // ...
})();
const acquireTheiaApi = acquireVsCodeApi;
delete window.parent;
delete window.top;
delete window.frameElement;    

Steps to Reproduce:

// vscode
globalThis.acquireVsCodeApi(); // OK
window.acquireVsCodeApi(); // OK
acquireVsCodeApi(); // OK

// theia
globalThis.acquireVsCodeApi(); // NO
window.acquireVsCodeApi(); // NO
acquireVsCodeApi(); // OK

Additional Information

• Operating System:
• Theia Version: 1.46.100
• Vscode Version: 1.86.1

[tsmaeder]

@dineug why would you assume that the function acquireVSCodeApi() is available on the window object? I have found neither documentation nor an example that implies that. Is there a concrete case where this is a problem?

[msujew]

@tsmaeder I would argue that even though it doesn't make a lot of sense, we should align to whatever weird behavior vscode has, just to keep plugin compatibility. Note that the change seems to be reasonable (related to notebook webview security, see https://github.com/microsoft/vscode/pull/109273).

[dineug]

@tsmaeder It seems like some plugins are being used because they work in VSCode. I also used them, but recently made changes.

https://github.com/excalidraw/excalidraw-vscode/blob/aaeb6c3d7eef780bd150f04793dee38270c3b53a/webview/src/vscode.ts#L15

https://github.com/dineug/erd-editor/commit/864d596429a4e4896516de301c37196885dee841