Webview and other views cannot remember their height

[tamuratak]

Version: 1.50.0-insider
Commit: cca20eb
Date: 2020-09-12T00:56:22.923Z
Electron: 9.3.0
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 17.7.0

I have tested the Webview View API. That greatly works. However, Webview views cannot remember their height. Expanding and collapsing them change their total height. How can extension authors work around it?

Steps to Reproduce:

1. Expanding and collapsing Webview views and other views.
2. Their total height gets much larger.

[alexr00]

@mjbvz this makes GHPRI look pretty bad as the webview-view ends up taking up most of the space: microsoft/vscode-pull-request-github#3227.

[mjbvz]

@alexr00 Are you still seeing this in the GitHub PR extension? I just tested but it seems like the view takes up half of the space

If you still see this, can you please provide specific steps to reproduce this?

[alexr00]

@mjbvz to repro:

1. Open change the format of CellUri#generate and #parse #141726 in your browser. I'm using Edge.
2. Hit "." for github.dev
3. Webview view takes up greater than half of the sidebar:
   
4. Don't do anything with the github.dev page.
5. Refresh the github.dev page.
6. Webview view takes up even more of the sidebar:
   

Please ignore the incorrect diffs in the screen shots. It's a known issue that I'll make a recovery release for in GHPRI this week!

[mjbvz]

Thanks. I can't yet reproduce this on desktop but can hit this on web following those steps

However I also reproduce this with the outline view if I move it into the Github PR view container so I don't think it's webview view specific

@alexr00 / @sbatten Do you have any pointers on how initial view sizes are computed?

[sbatten]

@mjbvz this is where we expand the views and set size.

vscode/src/vs/base/browser/ui/splitview/paneview.ts

Lines 141 to 167 in 4a130c4

	setExpanded(expanded: boolean): boolean {
	if (this._expanded === !!expanded) {
	return false;
	}
	if (this.element) {
	this.element.classList.toggle('expanded', expanded);
	}
	this._expanded = !!expanded;
	this.updateHeader();
	if (expanded) {
	if (typeof this.animationTimer === 'number') {
	clearTimeout(this.animationTimer);
	}
	append(this.element, this.body);
	} else {
	this.animationTimer = window.setTimeout(() => {
	this.body.remove();
	}, 200);
	}
	this._onDidChangeExpansionState.fire(expanded);
	this._onDidChange.fire(expanded ? this.expandedSize : undefined);
	return true;
	}

[mjbvz]

@alexr00 Is there an easy way to reproduce this with a local build? This is a complete pain to debug on GitHub.dev and I don't know how to get into this state in a local desktop/web build

[tamuratak]

Version: 1.66.0-insider (Universal)
Commit: 6dca4c1
Date: 2022-03-04T05:18:46.542Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin arm64 20.6.0

I still see the original issue on VS Code (Desktop). Notice the order of expanding. When reloading github.dev, I guess restoring views would be restored in the same order by chance, which causes the issue.

2022-03-04.18.41.29.mov

[mjbvz]

@tamuratak Thanks!

@sbatten Adding you since I can reproduce this using any types of views. I tested using the source control views that git lens adds which are all normal tree views, not webview views

[mjbvz]

I talked with @sbatten about this and we determined the original issue is by-design.

The most recent demo video shows why this is the case:

1. The lower view is collapsed and remembers its height
2. At this point the upper view now has a larger height to till in the space left open by the upper view
3. The upper view is then collapsed and also remembers its current height
4. We now start expanding the views again. First the lower view is expanded to its original height (from step 1)
5. Then the upper view is expanded to the height from (step 3)

This results in the overall height of both views increasing but both views were correctly preserving their height through all of the stages

We don't think there's a good way to fix this. The example above is a minimal repo, but there are many other ways that users could get into this situation with more complex sequences of actions

So I'm closing this specific issue as by-design but will open a new issue to continue investigating the issue with the GitHub pr extension seeing views not restored the the expected heights on first load / reload