Move the webview port mapping from renderer to main process #100342
Conversation
| @@ -468,10 +470,12 @@ export class NativeWindow extends Disposable { | |||
| // Register external URI resolver | |||
| this.openerService.registerExternalUriResolver({ | |||
| resolveExternalUri: async (uri: URI, options?: OpenOptions) => { | |||
| console.log('xxxxxxx'); | |||
| @@ -15,6 +15,10 @@ import { REMOTE_HOST_SCHEME } from 'vs/platform/remote/common/remoteHosts'; | |||
| import { IRequestService } from 'vs/platform/request/common/request'; | |||
| import { getWebviewContentMimeType } from 'vs/platform/webview/common/mimeTypes'; | |||
|
|
|||
|
|
|||
| export const webviewPartitionId = 'webview'; | |||
There was a problem hiding this comment.
Is this a temporary partition on purpose, because is only to intercept requests in a isolated way and not for persisting data to disk ?
There was a problem hiding this comment.
Yes we use partition to make sure that our onBeforeRequest handler only intercepts requests from webviews instead of being fired for all requests
I've also added a filter so that we only intercept localhost requests from webviews
There was a problem hiding this comment.
Just to note, if the partition is not persistent that is, if it doesn't start with persist:webview, then the storage for webviews will be temporary, cookies, web storage etc, network auth cache etc or any user data related to the browsing context will not be persisted to disk. Is that the intention here ?
There was a problem hiding this comment.
yes, right now webviews are supposed to be entirely ephemeral
There was a problem hiding this comment.
got it, thanks for confirming!
| return callback(redirect ? { redirectURL: redirect } : {}); | ||
| }); | ||
|
|
||
| this._register(toDisposable(() => protocol.unregisterProtocol(Schemas.vscodeWebviewResource))); |
There was a problem hiding this comment.
should use sess.protocol otherwise the unregistration happens on the default session.
Fixes microsoft#95955 Our port mapping impl for webview currently relies on `getWebContents` to handle port mapping in the renderer process. This API has been deprecated by electron. This change instead moves the webview port mapping handler to the main process. To make this change, I also realized that the tunnel service needed to be moved from `vs/workbench` to `vs/platform` so that we could consume it from the main process Other changes made as part of this refactoring: - Register all webview in a `webview` partition. This ensures that our port mapping manger only intercepts requests made inside webviews. - Send the `webContentsId` to the main process. This is required to implement `onBeforeRequest`. Unfortunatly the referrer always seems to be undefined for these requests - Have the tunnel service take a resolved authority instead of taking the raw authority. This was required due to the tunnel service moving to `vs/platform`
mjbvz
force-pushed
the
webview-port-mapping-on-main
branch
from
2597b45 to
8c4eaa1
Compare
Fixes #95955
Our port mapping implementation for webviews currently relies on
getWebContentsto handle port mapping in the renderer process. This API has been deprecated by electron. See #95955 for detailsThis change instead moves the webview port mapping handler to the main process. To support this, I also realized that the tunnel service needed to be moved from
vs/workbenchtovs/platformso that we could consume it from the main processOther changes made as part of this refactoring:
Register all webview in a
webviewpartition. This ensures that our port mapping manger only intercepts requests made inside webviews.Send the
webContentsIdto the main process. This is required to implementonBeforeRequest. Unfortunatly the referrer always seems to be undefined for these requestsHave the tunnel service take a resolved authority instead of taking the raw authority. This was required due to the tunnel service moving to
vs/platform