Skip to content

Agents - reduce toolbar flickering when switching between changesets#321986

Draft
lszomoru wants to merge 1 commit into
mainfrom
lszomoru/new-lobster
Draft

Agents - reduce toolbar flickering when switching between changesets#321986
lszomoru wants to merge 1 commit into
mainfrom
lszomoru/new-lobster

Conversation

@lszomoru

Copy link
Copy Markdown
Member

No description provided.

Copilot AI review requested due to automatic review settings June 18, 2026 19:19
@lszomoru lszomoru enabled auto-merge (squash) June 18, 2026 19:19
@lszomoru lszomoru self-assigned this Jun 18, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Not ready to approve

The new loading gating can leave stale toolbar actions active (including operations bound to the previous changeset) and can also incorrectly report loading when there is no active session.

Pull request overview

This PR targets UI stability in the Agents window “Changes” view by reducing toolbar flicker during changeset transitions, primarily by stabilizing layout and cutting down on unnecessary toolbar updates.

Changes:

  • Fix the actions container layout to a stable height to avoid visual jumping.
  • Treat “no active changeset yet” as a loading phase, and reduce reactive toolbar churn by adding value-based equality for menu actions.
  • Skip toolbar updates while loading to avoid transient re-renders.
File summaries
File Description
src/vs/sessions/contrib/changes/browser/media/changesView.css Adds a fixed height to the outside-card actions container to reduce layout flicker.
src/vs/sessions/contrib/changes/browser/changesViewModel.ts Adjusts loading detection to treat an undefined changeset as loading.
src/vs/sessions/contrib/changes/browser/changesView.ts Reduces toolbar updates by adding an equality comparer for menu actions and gating updates during loading.

Copilot's findings

  • Files reviewed: 3/3 changed files
  • Comments generated: 2

Note

Your feedback helps us improve the quality of this feature.
Please use 👍 or 👎 to tell us whether this assessment is correct.

Comment on lines 156 to 163
const isLoadingObs = derived(reader => {
const changeset = this.activeSessionChangesetObs.read(reader);
return changeset?.isLoadingChanges.read(reader) ?? false;
if (changeset === undefined) {
return true;
}

return changeset.isLoadingChanges.read(reader);
});
Comment on lines 326 to +331
this._register(autorun(reader => {
const isLoading = viewModel.activeSessionIsLoadingObs.read(reader);
if (isLoading) {
return;
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What version of the IDE extension are you using?

v26.616.30709

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 7.0.12-arch1-1 x86_64 unknown

What issue are you seeing?

All of a sudden, git status showed every file in my repo as deleted in my index (not in my working tree), and showed a whole bunch of files I didn't recognize as added (to the index, not the working tree). I chose a unique looking path segment for one of them—catalyst-by-zoho—and ran find ~ -type d -name catalyst-by-zoho. That revealed it was under ~/.codex/.tmp/plugins. I'm assuming this path must be used by the Codex extension during updates, and in the updater, there must be bug when setting GIT_INDEX_FILE that uses the current repo path instead of the updater's temp path.

Luckily, this is relatively harmless. I fixed it by truncating my index file with : > .git/index and repopulating it from my (luckily uncorrupt) head commit with git read-tree @. But this is kinda scary, because a slightly different mistake could have wiped my whole repo!

A lot of people who might find themselves in this situation might have a hard time figuring out how to fix it. Most git operations that consult the index when it's in this state will fail due to the presence of unknown objects. For instance, the "obvious" fix would have been git reset --mixed, but that failed with "fatal: unable to read 03906ea96e7708504c5986a28f385754a34ccd7f".

What steps can reproduce the bug?

No idea. I hadn't even used the extension in the past week. I'm assuming the auto-updater did this.

What is the expected behavior?

Don't currupt my repo!

Additional information

No response

@lszomoru lszomoru marked this pull request as draft June 18, 2026 19:28
auto-merge was automatically disabled June 18, 2026 19:28

Pull request was converted to draft

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants