This is no longer be needed. We still serve the webview code itself from a unique subdomain
This also removes the need for `serviceWorkerFetchIgnoreSubdomain`
* Simplify logic for webview resource uris
This change attempts to simplify the logic around webview resource uris by doing the following:
- Hard code the resource origin. We always will be hitting a service worker for these paths so they don't need to be dynamic (although in the future we may want to pull them from `product.json`)
This lets us remove these properties from the environment service
- Move remote handling from the resource loader in `asWebviewUri`.
- Remove the handling of http and https paths from the resource loader.
I don't think these cases can be hit any longer (although I need to confirm this with more testing for the web case). Instead I added a check to `asWebviewUri` so that we return the original uri if a http(s) uri is passed in
* Restore normalizeResourcePath
We still need to convert between a remote uri and one that our remote file system can read
* Fix test
* Restore passing in remote on extension side
* Remove only
* 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 proposed webview view API
For #46585
This adds a new `WebviewView` proposed api to VS Code that lets webview be used inside views. Webview views can be contributed using a contribution point such as :
```json
"views": {
"explorer": [
{
"type": "webview",
"id": "cats.cat",
"name": "Cats",
"visibility": "visible"
}
]
},
```
* Use proper activation event
* Transparent background
* Fix resize observer
* Adding documentation
* Move webview view to new directory under workbench
* Remove resolver
By moving the webviews view into their own fodler, I was able to avoid the cycle the resolver was originally introduced for
* Use enum in more places
* Hook up title and visible properties for webview views
* Remove test view
* Prefer Thenable
* Add unknown view type error to collector
Fixes#95854Fixes#95849
For #77131
- Move all editing functionality back onto the provider. This better matches the notebook API.
- Rename `CustomEditorProvider` to `CustomReadonlyEditorProvider`. `CustomEditorProvider` is now how editable custom editors are implemented
- Give extension a full suggested backup path instead of just a folder
Fixes#95846Fixes#95851
For #77131
- Rename `EditableCustomDocument` to `CustomEditableDocument`
- Rename `CustomDocumentBackup.dispose` to `CustomDocumentBackup.delete` to make it clearer how this is supposed to be used
- Rename `OpenCustomDocumentContext` to `CustomDocumentOpenContext`
- Add a context to backup. Pass in `workspaceStorageUri`
For #77131
- Rename `onDidEdit` to `onDidChange`
- Allow custom editors to fire a `CustomDocumentContentChangeEvent` that only marks the editor as dirty but does not enable undo/redo. The only way for editor to get out of this dirty state is to either save or revert the file
For #77131Fixes#93963Fixes#94515Fixes#94517Fixes#94527Fixes#94509Fixes#94514Fixes#93996Fixes#93913
This removes explicit edits from the API and reshapes the API to more closely match VS Code's internal API. The change also tries to better express the lifecycle of backups
For #77131
- Use a class for `CustomDocument` instead of an interface. Extensions can now add their own data to a `CustomDocument` by sublassing
- Renamed `resolveCustomDocument` to `openCustomDocument` and require that extensions return a `CustomDocument`
- Exposed edits on `CustomDocument`
- Made the third parameter of `registerCustomEditorProvider` a generic options bag that takes a `webviewOptions`
For #77131
Going back the the delegate based model for a few reasons:
- It gives us a better approach to add additional API hooks in the future (such as for rename)
- In practive, the capabilities were almost always the same as the `userData` on the document. It is rather confusing to have both `userData` and the capabilities 'on' the document
* Use the UndoRedoService for CustomEditors
For #90110
Changes custom editors (the ones not based on text) to use the UndoRedoService. This involved:
- Moving edit lifecycle back into the main process again (this is actually the bulk of the changes)
- Removing the `undo`/`redo` methods on `CustomEditorModel`
- Using the undoRedoService to trigger undo/redo
Fixes#91670
- Move model type logic out of `CustomEditorInput` and into two different implementations of `ICustomEditorModel`
- Add `CustomTextEditorModel` that owns a proper model reference to a text document. This should ensure the text document is disposed of if there are no more references to it
- Move most of the previous `CustomEditorModel` into `mainThreadWebviews` directly. This removes some of the indirection that was previously required (such as using `waitUntil`)
