View height does not update when adjacent container's height changes

[joyceerhl]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.66-insider
• OS Version: Windows 11

Steps to Reproduce:

1. Drag outline section into the search activity bar view container
2. Run a search with the outline section expanded
3. Collapse the outline search
4. 🐛 results appear truncated because the list height isn't updated

[JacksonKearl]

Able to hit this consistently on my Windows vm but have never seen it on Mac. Perhaps a timing bug where we're measuring the container too early.

[JacksonKearl]

Ah, doesn't repro when motion is disabled. So the search tree tries to measure its height right when it gets the layoutBody call, but at that moment the animation hasn't finished so it measures the old height instead of the new one. @sbatten could you signal when the animation is over? layoutBody does get passed height information, but search view prefers to let the tree view measure its container because there can be a lot of other elements taking up differing amounts of space in it (whether includes are expanded, replace, search messages, etc). cc @roblourens too

vscode/src/vs/workbench/contrib/search/browser/searchView.ts

Lines 1056 to 1076 in d675c04

	private reLayout(): void {
	if (this.isDisposed || !this.size) {
	return;
	}
	const actionsPosition = this.searchConfig.actionsPosition;
	this.getContainer().classList.toggle(SearchView.ACTIONS_RIGHT_CLASS_NAME, actionsPosition === 'right');
	this.searchWidget.setWidth(this.size.width - 28 /* container margin */);
	this.inputPatternExcludes.setWidth(this.size.width - 28 /* container margin */);
	this.inputPatternIncludes.setWidth(this.size.width - 28 /* container margin */);
	this.tree.layout(); // The tree will measure its container
	}
	protected override layoutBody(height: number, width: number): void {
	super.layoutBody(height, width);
	this.size = new dom.Dimension(width, height);
	this.reLayout();
	}

[JacksonKearl]

Ended up just measuring element height, ended up with a but of a fuzz factor I rolled into "margin".

[roblourens]

I think this is basically what it used to do, which apparently had an issue: #116182

I'm not sure why measuring the height outside the tree had this issue with scaling but the measurement inside the tree was ok. But could you test it with a zoom factor like in that issue?

[JacksonKearl]

And I even verified it back then.

But testing now on MacOS with some different scaling settings and my Windows VM across a variety of resolutions (100,125,150,175,200,225,250,400), I haven't been able to spot that coming up.

Though it's perhaps worth noting my eyes aren't excelling at distinguishing nearby horizontal lines at the moment.

@joaomoreno are you able to verify with your setup?

[joaomoreno]

Seems OK to me on Insiders today.

[joaomoreno]

Nope, can't scroll more here, despite there being obvious tree rows in there:

Repro:

• Search for new Promise<void>(resolve, no search flags active

Bug first spotted by @bpasero

[bpasero]

Marking important as I lost search results to work on because of this.