Avoid firing _onDidChangeItemHeight when row height is only being initialized

[roblourens]

Alternate proposal for #314882

For #293359

[Copilot]

Pull request overview

This PR adjusts ChatListItemRenderer.fireItemHeightChange to avoid emitting the _onDidChangeItemHeight event when the row height is being initialized, by only firing the event if there was a previously stored numeric height.

Changes:

• Track the previous currentRenderedHeight before overwriting it.
• Gate _onDidChangeItemHeight.fire(...) behind an additional typeof originalStoredHeight === 'number' check.

Show a summary per file

File	Description
src/vs/workbench/contrib/chat/browser/widget/chatListRenderer.ts	Changes height-change event emission logic by capturing the original stored height and adding an additional guard before firing the event.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 1

[bryanchen-d]

Should this check be originalStoredHeight === undefined?

I think it should work to avoid the re-flow, just have a concern: will this break the spec of _onDidChangeItemHeight? my mental model for this event is that it should fire whenever the height got changed, and in the first entry here, it did change from a 'undefined' state (with a default height) to another height.

[roblourens]

Should this check be originalStoredHeight === undefined

I think I want to fire the event when the original height was already initialized

I think it should work to avoid the re-flow, just have a concern: will this break the spec of _onDidChangeItemHeight? my mental model for this event is that it should fire whenever the height got changed, and in the first entry here, it did change from a 'undefined' state (with a default height) to another height.

It's a bit weird, but we need to fire the event when the row's height changed after it was rendered, not when it was simply initialized. Then we pass that on to the list.

[roblourens]

Let's merge this on Monday (for 1.121) if that's ok with you, it may be risky