Add experimental support for using iframes for webviews #100991
Conversation
|
@rebornix You should be able to the new |
| @@ -13,7 +13,7 @@ export const IWebviewManagerService = createDecorator<IWebviewManagerService>('w | |||
| export interface IWebviewManagerService { | |||
| _serviceBrand: unknown; | |||
|
|
|||
| registerWebview(id: string, webContentsId: number, metadata: RegisterWebviewMetadata): Promise<void>; | |||
| registerWebview(id: string, webContentsId: number | undefined, metadata: RegisterWebviewMetadata): Promise<void>; | |||
There was a problem hiding this comment.
I need to figure out what the equivalent of webContentsId for iframe based webviews. We need this for intercepting the localhost request for remote
There was a problem hiding this comment.
@deepak1556 Here is the problem I am trying to solve:
-
For port forwarding in remote cases, we use a
onBeforeRequestthat looks at requests tolocalhostand potentially rewrites them -
There is a single
onBeforeRequesthandler for all webviews -
When using the
<webview>tag, we were able to identify which webview was making the request to localhost using the web contents id. We would then use this id to lookup the port mapping information for that webview -
However iframes do not have a unique web contents id (at least, not by default) I cannot find any way to map a request that comes in to
onBeforeRequestback to the webview that triggered the request.
Here are the fields I see on the details object in onBeforeRequest
Any thoughts on how we could handle this mapping?
There was a problem hiding this comment.
@mjbvz I can extend the webrequest api to provide some addtional event details that would include the frame origin and frame name, do you think its good enough to manage the port map ?
vscode-webview://787e559f-185c-4d86-aebc-400191530e52/...
<iframe name="test" >
then details will have
{
isSubFrame: true, // if the request originated from a subframe
origin: '787e559f-185c-4d86-aebc-400191530e52', // last committed origin of the frame
name: 'test', // value of the name attribute for a subframe
....
}
There was a problem hiding this comment.
Yes that would work great for us here. Should I open a feature request against electron?
There was a problem hiding this comment.
Yes please do, I will put up a PR targeting it. Thanks!
There was a problem hiding this comment.
Great! Opened electron/electron#24303 for this
Adds a new `vscode-webview` protocol for loading the wrapper contents of a webview Still needs cleaning up
mjbvz
force-pushed
the
mjbvz/offline-iframe-webviews
branch
from
5ff3b28 to
63e22da
Compare
|
Merging the initial support so we can test it more. Desktop vscode will continue using webview unless you set |
This changes enables using normal iframes to power webviews in desktop VS Code. Previously this required an internet connection so we could load the iframe content from an external webview. With this PR, we now use a new
vscode-webviewprotocol so that we can load the webview content locally.A new undocumented setting
webview.experimental.useIframesthat enables these using iframes for webviews.