Tags: microsoft/vscode
Tags
Pre-seed Integrated Browser smoke settings to avoid the relaunch prom… …pt (#328972) Pre-seed browser smoke settings instead of writing them at runtime Setting window.menuStyle through the settings editor made SettingsChangeRelauncher pop a modal 'restart to take effect' dialog on Windows/Linux, which blocked the workbench and broke the first test. Seeding both settings on disk before launch means the values are already in effect when the window opens, so no relaunch prompt appears. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Correct the error message to show when Host restricts bwrap execution (… …#327766) * Enabling running sandbox inside containers Signed-off-by: Dileep Yavanmandha <dileepy@microsoft.com> * Updating notification message incase of sandbox error * Update bubblewrap host restriction test * Fix AppArmor remediation test setup * test: stabilize run in terminal tool suite * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Revert "Potential fix for pull request finding" This reverts commit e574378. * Clarify sandbox host restriction message --------- Signed-off-by: Dileep Yavanmandha <dileepy@microsoft.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
fix: restore 8 KiB Node buffer pool on linux (#326334) Node 24.18 changed Buffer.poolSize from 8 KiB to 64 KiB in nodejs/node@d3ef412 Node uses the pool for Buffer allocations smaller than half the pool size. As a result, allocations below 32 KiB can now be views into a shared 64 KiB backing ArrayBuffer. VS Code's VSBuffer preserves these pooled backing stores. Webview resource streaming then forwards Uint8Array views through transferable streams without copying just the visible byte range. Structured clone consequently serializes the full 64 KiB backing store. Chromium's mojo_base::BigBuffer has a 64 KiB inline limit. The structured-clone envelope makes these payloads just above that limit, so each message switches from inline storage to writable shared memory. On POSIX, each writable shared-memory region carries two file descriptors: its writable descriptor and a read-only descriptor used for conversion. Under a renderer RLIMIT_NOFILE of 1024, a burst of webview resource messages therefore consumes two descriptors per chunk. Instrumentation of VS Code loading the Codex webview showed: - 1,910 large CommonCloneableMessage serializations; - the dominant payload sizes were 65,556 and 65,557 bytes; - renderer descriptors increasing through 1021, 1022, and 1023; - recvmsg() returning message bytes with MSG_CTRUNC once descriptors could no longer be installed; - Mojo buffering messages with missing handles; - subsequent resource failures and service-worker Cache.put() network errors. Restoring the previous 8 KiB pool size prevents small VS Code buffers from retaining 64 KiB backing stores. Their structured-clone messages remain below BigBuffer's inline threshold and no longer require shared-memory descriptor pairs. Instrumentation with this override removed the 65,556/65,557-byte message burst and avoided the original stale-FD reassociation and clean renderer exit. Larger shared-memory messages can still exhaust descriptors under sufficiently heavy pressure, so this is a targeted mitigation rather than a replacement for the Mojo MSG_CTRUNC fix. Node's default pool size.
[Cherry-pick] Remove last-used session type and agent logic (#323484) (… …#324826) * cherry-pick b802a62 * signing commit * Fix test * Revert PR #324669 * Revert "Revert PR #324669" This reverts commit d97c4e5. * Preserve explicit local chat session branch * Remove IStorageService --------- Co-authored-by: Don Jayamanne <don.jayamanne@outlook.com>
PreviousNext