It's possible that using browser storage makes more sense with settings
sync, so we might want to revisit this once/if we get settings sync
working. As it currently is though, browser storage just causes jank.
The path was also missing a `User` at the end so I added that. This
might affect the Vim extension which would have been writing to the
wrong path previously but I don't believe it should affect anything
else since they would have been writing to browser storage.
- Fixes#2208
- Fixes#2231
- Fixes#2279
- Fixes#2274
The telemetry service depends on this now. I had to move it into
invokeFunction and use accessor.get otherwise getLogger on the service
was undefined.
I also had to move some the extension management service because it
depends on the moved telemetry service. I moved a few other services as
well to better match VS Code (sharedProcessMain.ts).
I swapped some this.services.get with accessor.get since that seems to
be the correct method although for these other services either method
seems to work.
This way the connection can be initiated by either side. It looks like
sometimes the initial message from the client is lost (it never makes it
into the onControlMessage callback) but I'm still not sure why or if
that is preventable.
Also added a timeout on the server end to clean things up in case the
client never responds.
Removing them just for peace of mind even though they seem to get
filtered out later. This line is meant to only add remote extensions
that aren't capable of running in the browser. If they are
browser-capable they don't need to run in our shimmed Node environment.
This makes the fetch work independently of the worker's origin which is
no longer the same as the main thread (the main problem is the inability
to send cookies without setting SameSite to None).
- The .js build files are no longer committed so they're gone.
- ParsedArgs and EnvironmentService are now NativeParsedArgs and
NativeEnvironmentService.
- Interface for environment service was moved.
- getPathFromAmdModule was deprecated.
VS Code has a short delay before writing storage (probably to queue up
rapid changes). In the web version of VS Code this happens on the client
which means if the page is reloaded before the delay expires the write
never happens.
Storage updates are already promises so this simply returns the promise
returned by the delayer so it won't resolve until the write actually
happens.
Fixes#2021.
Add initial support for opening files / folders in running code-server instance.
Current limitations:
- unable to open a file in a new window, only folders
- unable to use addMode feature
- others...
It can still be used to check for updates but will not apply them.
For now also remove the update check loop in VS Code since it's
currently unused (update check is hardcoded off right now) and won't
work anyway since it also applies the update which now won't work. In
the future we should integrate the check into the browser update
service.
Asher