On desktop, we now serve webview resources from a different origin than the webview itself. This means we no longer can use `'self'` in our CSP as shorthand and instead should always use the provided `cspSource`
Fixes#113511
This tracks the id of the currently active custom editor
This change also removes the 'customEditors' context. This was an old context specific to custom editors and has since been replaced by the more generic `activeEditorAvailableEditorIds` context
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
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
Create a temporary overload for testing `CustomEditor`. In finalization, we'd update `registerCustomEditorProvider` to take both types of custom editor instead
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
