'webview.getWebContents()' is deprecated and will be removed

[bpasero]

Please use 'remote.webContents.fromId(webview.getWebContentsId())' instead

Seeing this in my E8 exploration build console. I am not sure we want to support the usage of the remote module. Maybe we can do this access alternatively not requiring it at all?

//cc @deepak1556

[bpasero]

Looks like https://www.electronjs.org/docs/breaking-changes#deprecated-webviewgetwebcontents outlines a solution without remote module.

[mjbvz]

@bpasero @deepak1556 We use the web contents in a few different ways:

• vscode/src/vs/workbench/contrib/webview/electron-browser/webviewElement.ts

  Line 84 in e0015ab

  contents.session.webRequest.onBeforeRequest(async (details, callback) => {

• vscode/src/vs/workbench/contrib/webview/electron-browser/webviewElement.ts

  Line 219 in e0015ab

  contents?.setIgnoreMenuShortcuts(value);

Moving all of these to use ipc will be difficult. There may be some other electron APIs that can help us here though

This doesn't block updating electron 8 though, correct?

[deepak1556]

This doesn't block electron 8 but will block electron 9 exploration.

Moving all of these to use ipc will be difficult

Can you expand on this ?

Whatever method is being used on webview.getWebContents(), all of them are internally forwarded to the main process over ipc by electron, so any usage we have now can be moved without relying on webContents directly in the renderer.

Also caching the webContents on the renderer side is not a good idea as there is no clear signal for the destruction path, which can lead to issues like #96207 . Handling the webContents method on the main process will avoid such issues.

[bpasero]

@deepak1556 does it make sense to push this any further given we already know that webcontents will not work with context isolation? How would the solution look like for iframe?

Can you maybe clarify what the exact conditions are, because I thought about enabling preload+contextIsolation this month, but maybe we cannot do that until we are off webview?

[deepak1556]

@bpasero we need a bit of planning here on how to tackle this over the next few iterations.

1. webview.getWebContents() is removed from Electron 9, so current webview usage cannot work after with it moving forward.

2. when using webview under contextIsolation, electron will throw a deprecation log in the devtools console

Security Warning: A WebContents was just created with both webviewTag and contextIsolation enabled. This combination is fundamentally less secure and effectively bypasses the protections of contextIsolation. We strongly recommend you move away from webviews to OOPIF or BrowserView in order for your app to be more secure

But the usage has not been blocked in electron master yet and it will most likely happen with electron v12 which gives us time to transition to OOPIF based implementation.

Given the above we can start the work for preload+contextIsolation in this iteration and in parallel start exploring the transition to OOPIF which will atleast take one or two iterations.

In this iteration, I am exploring #96307 which is one of the blocker for iframe transition. And the actual work to transition can happen in June or July depending on @mjbvz availability.

And to answer the main question of fixing the usage of webview.getWebContents, we should do it if we want to adopt electron 9 and higher, but if we can wait a couple more iterations for the iframe transition to finish then this work can be avoided.

Just to reiterate the transition to OOPIF will not block adopting preload+contextIsolation work, so please go ahead with it :)

[mjbvz]

I quickly explored two other approaches for serving up the content for the webview (the stuff that we control). These would (ideally) let us move away from custom protocols but I couldn't get either working :

• Use protocol.interceptHttpProtocol to intercept requests to vscode-webview-test.com

  I couldn't get this working for https requests. There also does not appear to be a way to limit which requests are intercepted. Also, I always ended up either crashing VS Code or getting into an intercept loop when I tried using these

• Use webRequest.onBeforeRequest

  This doesn't seem to provide enough flexibly for serving up custom content when a request is made

[bpasero]

@deepak1556 it looks like this was the last dependency on remote module, so I think we can now configure enableRemoteModule: false for all our windows, would you agree?

[deepak1556]

@bpasero yes that would be safe to add now.