* add integration tests for LanguageModelChat#sendRequest
* make sure errors are recreated when making LM requests
* disable test with a note for later
* fix remote integration tests
* Add more logging and perf markers around resolving the connection token and the socket factory
* set `exposeFunction` earlier
* bla windows
* also expose function for unit tests beofre opening
Co-authored-by: Benjamin Pasero <benjamin.pasero@microsoft.com>
* Allow reusing webview origins across reloads
Currently webviews are always loaded into a unique origin. This keeps them isolated but also means that we can't benefit from caching across window reloads
This change adds a new `origin` option that you can pass to webviews which controls the origin they use. If this origin is not provided, we use a random one instead
We then save off this origin for webview panels and restore it on window reloads. Webviews restore a little faster on window reload
* Update webview fallback version
* web - first cut `yarn web` via our server
* properly pipe output
* web - remove traces of web playground
* web - remember last opened workspace for convinience
* use vscode-test-web for server less, clean up web commands
* fix comment
* fix `yarn web`
* rename to code-server
* open system browser
* code-server script: use minimist
* test resolver: use ./scripts/code-server
* integartion tests: fix code-server command name
Co-authored-by: Martin Aeschlimann <martinae@microsoft.com>
* Revert service worker usage of MessageChannel
Reverts 66b6adf035
While I'm not 100% about this, I think 66b6adf035 causes resourses to occasionally not load. I believe this can happen if the service worker is unitilized while the webview remains active. I can't reproduce this myself so it may be related to memory pressure or resource usage, however relying on the service worker not being reinitilized does seem like a potentially bad idea https://stackoverflow.com/questions/34775105/what-causes-the-global-context-of-a-service-worker-to-be-reset
Will investigate if there's another way to achive this since using MessagePort did clean up the code and slightly improve performance
* Bump webview commit versions
* Switch webview service-worker to use message channel
This change hooks the service worker used for loading webview resources directly up to the main VS Code process over a message channel. Previously this communication had to go through an extra hop through the webview
This simplifies the logic somewhat (although this change required adding extra logic to exchange the message port). It also improves performance a little
* Update webview content commit version
* Enable webview tests on web
These tests pass fine on Chrome and webkit. On Firefox, the two about loading resources currently fail
I spent a while trying to debug what is going on with these tests. It seems like the service workers is registered properly but `fetch` is never called on it. Skipping these for now
* Remove only
* Fix test
* first cut upload log files from integration test runs
* always publish log files
* move logs into integration-tests folder
* also produce logs for smoke tests
* store remote log files
* wire in logspath arg properly
* always publish logs
* enable logs for browser based smoke tests
* log only in verbose