* Improve passing of ArrayBuffers to and from webviews
Fixes#115807
* Serialize and restore typed arrays too
This also makes it so that if you pass the same ArrayBuffer twice in an object, we use a single object on the receiver side too
* Fix spelling
* Require VS Code 1.56+
- Move protocol types into protocol
- Hold off on combining the options objects until serialization
- Add explicit converstions instead of using `...`
- Make a few methods take property bags to help avoid passing arguments in wrong order
* Add vscode-webview-resource protocol
Adds a new protocol (`vscode-webview-resource`) for loading resources insides of webviews. This replaces the existing `vscode-resource` protocol and is registered on the main thread instead of in each renderer
This change also adds some rewriting logic to update any `vscode-resource:` references found in the main html to use `vscode-webview-resource` instead.
* Move webview protcol provider to own file
* Remove registration of vscode-resource scheme
* Remove use or parition for each webview
Now that we have a single shared protocol handler, we do not need to run each webview in its own partition
* Fix rewriting csp to use new protocol
* Update src/vs/code/electron-main/app.ts
Co-authored-by: Benjamin Pasero <benjpas@microsoft.com>
Co-authored-by: Benjamin Pasero <benjpas@microsoft.com>
This fixes an issue where webviews for custom editors did not have any associated extension information, which caused them try reading `file:` uri resources instead of remote uri resources
- make it unlikely that a new view instance would accept a view zone id from a previous view instance
- remove that the find widget removes a view zone id from another view
(fixes#71745)
This change attempts to do the following:
- Encapsult most of the logic for handling the webviews used for webview editors into a new WebviewEditorOverlay class
- Greatly simplify WebviewEditorInput and make it take a webview when it is created
- Move the webview creation logic up into the webviewEditorService instead of having it be inside the webviewEditor class itself
This aim of these changes is to make it possible to re-use more of the webview logic for custom editors
