The browser writes some workspace files to the client disk during normal
use. The webview service worker stores resources that have an ETag in
Cache Storage, and responses from /vscode-remote-resource can end up in
the HTTP disk cache. --disable-file-downloads does not cover either.
With --disable-file-cache, the webview resource loader sends no ETag for
a resource outside the webview's own extension, so the service worker
does not store it. /vscode-remote-resource responds with
`Cache-Control: no-store` for files outside the extension directories.
Extension files keep their ETags, so webviews still load extension code
from the cache. The flag is off by default.
* Update Code to 1.139.1
* Bump proxy-addr to 2.0.8
* Add preinstall setup to build
Already had this in the release build step, not sure why it is not in
the main build step. But we started getting errors building native
modules in ci, and this seems to be why.
* Fix quick input
It types too quickly, before the input is visible.
* Update Code to 1.136.1
* Do not click on tab during test file opens
It will already be the selected tab, and if any other tab is already
open (like the welcome tab), it will click that instead.
We disable the welcome page so this is not supposed to actually matter,
but that Setting appears not to be working.
Also add the quick input widget selector in the disabled downloads test,
since if the widget never shows up it would mistakenly pass.
The problem was that whenever the hashe needed an update, the current
patch would create a conflict which cannot be easily auto-resolved.
Instead, put the hashes in a separate patch that is deleted and
regenerated each time, avoiding the conflicts.
Also the web worker iframe hash was not being updated.
* Update Code to 1.116.0
* Add copilot extension build
Seems the vscode build requires this separately now.
* Disable welcome popup
A giant modal window asking you to sign in for AI features is blocking
the tests. Rather than have to click through it, disable it. It looks like
this has to be a user setting, so switch to that instead of machine (we
used machine because user settings were in the browser, but they have
been since moved back to disk).
---------
Co-authored-by: Asher <ash@coder.com>
* Update Code to 1.113.0
* Use CI build targets
The target we have been using has started throwing all sorts of errors
during the build (even without any of our patches). After checking the
VS Code repo I think these are the ones we should actually be using.
They are way faster, too.
---------
Co-authored-by: Asher <ash@coder.com>
cdrci