Change:
import { ScrollEvent } from 'vs/base/common/scrollable'; import 'vs/css!./paneview'; import { localize } from 'vs/nls'; <del> import { IView, SplitView } from './splitview'; </del> <ins> import { IView, Sizing, SplitView } from './splitview'; </ins> export interface IPaneOptions { minimumBodySize?: number;

Discussion:
This tracks the issue discovered in See for this discussion as well. We originally thought that issue had the same root causes as this one, but investigation revealed that was not the case
I've debugged this in an OSS build. It's a difficult consistently hitting the original issue from but I do some really odd behavior around view state being saved and restored Here's what I was doing: active PR view the views window back to active PR view once it is loaded After step 2, I see the following data being written for the views in : ! However when the state is then restored by , I see the following data being loaded (look at the sizes specifically): ! Will try to track down if some other code is writing this incorrect size data or if the reload is somehow restoring it incorrectly on reload
Adding and to see if you have any ideas about what's going on here. I've been debugging through the storage calls (at least on the renderer side) and we seem be writing the values as expected but on reload we still get back the incorrect values
Reopening this as I'm still seeing this issue on
After debugging further, here's what is happening: Basics: The GitHub PR view contains 3 views (from top to bottom): , , On reload with a PR, all 3 of these views start as visible. The PR extension then hides the view by updating a context key Bug: window view is created first After finishes, we have the sizes: we add After finishes, we have the sizes: we add The sizes are now now call for the various views (in a loop) Here however, we have very large saved view size for (1012) This means that when we do for the welcome view, the other two views to become quite small. In my testing after finishes here, the sizes of the three views are: then remove the view (I believe this is triggered by the PR extension changing the view's context key) causes the last view () to fill in the now empty space below it complete this time, the sizes of the two remaining views are: So in summary: the view has a very large saved view size (presumably from initial load) and this large size effects the sizes of the other two views even though the welcome view is immediately hidden However I don't know what the proper fix for this. Should we try saving off the fact that the welcome view has been conditionally hidden for example?

Should we try saving a more accurate size for the welcome view? I think I've made about as much progress as I reasonable can in this space without any real understand of the view code. Can you please take this issue from here?
Thank you for looking into this and tracking it down .
Sure - thanks for update
To be clear, is this the bug we are planning to fix? (After refresh the bottom view is taking more space) https://user-
Yes, that's the one.
I can reproduce this behaviour with following sample extension <details<summaryExtension</summary</detailshttps://user- analysis is correct In the beginning first 2 views are visible and are sized equal. After 5 seconds, third view comes in and sizes are still distributed. After 2 seconds, third view is made hidden by setting the context. At this point, last view is removed and its space is allocated to the view (second view) before last view. First view takes 33% and Second view takes 67% of the total size. Instead the removed size shall be equally distributed to all visible views. Used DistributeSizing option while removing the pane and this seems to fix it. https://user- CC - I do not have much experience in using split views and do not know what are the side affects of using option. So please take a look and update/enhance the fix if needed.
Great analysis! the docs say: ! Which means: When using in , all other views will be resized to distribute the total splitview size. Without that option, the regular layout algorithm will happen... usually that means that only the adjacent view will stretch.
I am not sure if the following doc says the same or I am wrong: As per the doc, I was expecting that the removed view space is distributed equally across other views. But it is not and it is doing as you mentioned. This also explains why the views sizes are getting reset to equal sizes after a view is removed (when DistributeSizing option was used).
Thanks for calling that out! I'm improved the docs there.
Given that it is not doing what I am expecting - removed view space is distributed equally across other views. Is there an other option to achieve this?
Not today, no.

It means the above fix has the side affect that views sizes get reset when a view is removed - which I think is ok. CC
First off, thank you all for your investigations. however, I'm not sure this is a viable solution. Any time a view is removed this will resize all views which can feel quite wrong. See the gif below where we hide the outline view. The only other expanded view is quite small and becomes now half of my screen. The same can happen with drag and drop of views as well. !
I agree the new behaviour is not ideal but it is acceptable when compared to existing. Probably we can improvise it by not to distribute space when the view is collapsed? BTW I also observe the same in editor groups. https://user-
I've approved the PR. I think the change we have made is a band-aid that helps, but doesn't cut to the root of the problem. I thought through various view/hide scenarios and in each case, I had a different feeling about what I expected to happen with the sizing of the views. IMO, our previous behavior was more correct from the pane view side as an intentional "hide" operation on a view should not redistribute every view in the container. However, the problem here is that there is a problematic extra view that is not controlled by the user. In this case, we are just trying to get sane sizing. If we invest more time in this, I think the fix lives at a higher layer.