Fixes#123494
This change attempts to address issues where `asWebviewUri` could create an valid uri but an invalid http uri. This issue appears to be when the host contains a forbidden character (even if it is percent encoded): https://url.spec.whatwg.org/#forbidden-host-code-point
Having one of these characters in the host causes the url to become invalid, resulting in network requests never being made
To fix this, I've added a very simple (poor) encoding mechanism for the authority. I went with my own mechanism over something like base64 because base64 can output `/` and it's also not easy to use across both node and browsers. I also considered base62 and punycode, but both of these would be best to pull in libraries for
* first pass at adding api
(cherry picked from commit 8a583c52ee)
* add task2 remaining changes
* remove unnecessary changes
* modify tasks.json directly for test
* reset tasks in test
* Fix compilation errors
Co-authored-by: Alex Ross <alros@microsoft.com>
This is no longer be needed. We still serve the webview code itself from a unique subdomain
This also removes the need for `serviceWorkerFetchIgnoreSubdomain`
## Problem
Webview uris currently have the form:
```
https://uuid.vscode-webview.net/vscode-resource/scheme/authority/path...
```
We have this syntax because we need to be able to recover the original scheme and authority of the resource in order to load it from disk
However this syntax means that absolute urls don't behave as you'd expect. For example, if you have a webview that sets a `<base>` to a document in the workspace, an absolute url `/abs/path.png` ends up being resolved to:
```
https://uuid.vscode-webview.net/abs/path.png
```
This drops the original scheme and authority, which prevents us from loading the resource
## Fix
With this change, I've moved the original scheme and authority into the authority of the webview uri instead of the path:
```
https://scheme+authority.vscode-resource.uuid.vscode-webview.net/path...
```
With this change, absolute paths should correctly be resolved
This moves us off of `vscode-webview-test` to instead use `vscode-webview.net` for loading webview resources. We now also pick this up from the product.json instead of hardcoding it
* 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
When the core references `vscode`, we only want to import the types and never generate a real import (which will fail to load). Use `import type` to better enforce this
Fixes#81434
- Make image preview a ui exension
- Add logic so that `asWebviewUri` supports preserving the scheme of the requested resource. This is important as we know where to load the resource from
* Adopt TerminalVirtualProcess for Custom task execution
* Update Custom task execution API to return TerminalVirtualProcess in callback
This also required the addtion of a start on the virtual terminal process
* Clarify start API
Fixes#76492
