Preserve window size when restoring a maximized window

[prasannavl]

The window size is not preserved, if VSCode is closed being maximized.
The correct behavior should be that it restore to the previous un-maximized size, when restored.

[mackenza]

what platform?

[prasannavl]

Windows.

But I suspect, it should be a problem with all platforms unless the window managers override it, which could hide the problem.

[mackenza]

where did this standard of restoring un-maximized when you shut down maximized come from? I am on Linux (Mint Cinnamon) and every app I tried restored maximized if I shut it down maximized. I am not around my Windows machines right now so can't test there. Is this in some sort of Windows style guide item?

[prasannavl]

I'm afraid there's really no style guide in that aspect. But Windows always properly stores the window sizes, and its a convention that's just in practice, unless an application overrides it explicitly.

This deviates from it.

Just to clarify, yes it opens maximized, if it shuts down maximized - that's correct behavior. But when you restore it now, it loses its actual size when not maximized.

Technically, its an Electron bug, where it only stores the last size, which when maximized is the maximized size instead of the restored window size. VSCode, since v0.10 works around it by setting itself to a default size instead of the old electron behavior which is worse - since it'll have the maximized size as the previous size (which is the case in previous versions - where when you unmaximize, it will have a size which is again the maximized size).

[bpasero]

Yeah, known issue.

[regs01]

This could be related
If there is any VS Code window is open, new instance resets window size to default. Still there as of 0.10.11.

[bpasero]

Well we open any Nth window (for N > 1) in the default size, what would you expect otherwise?

[regs01]

well, i more expect size i want, cause i have to resize the tiny window every time i open it. just save the last size and use it always until any window get resized.

[bpasero]

@regs01 so you would expect the second window to open with the size of the window that is already open?

[regs01]

@bpasero kind of. so i just resize it once and it will save my size, then any instance, no matter if 1st, 2nd or 3rd will open with my size. well, any other app does like this.

[bpasero]

@regs01 I suggest you open a separate issue on that topic as this one here talks about a different problem.

[prasannavl]

@bpasero I'd say that the point made by @regs01 and this are highly related. So much so, that fixing this unless explicitly overridden should fix that as well naturally.

The idea is that whenever a window is created, it should now use the last saved size. Now, the intricate detail here is that the last saved size should never be the maximized size. (If the window is maximized when it quits, it should rather save the size before maximization with an isMaximized flag). And any window that's created uses this size and flag on creation.

[prasannavl]

Pseudocode (It doesn't reflect electron's api. Just the idea. Variables names may also be exceedingly verbose on purpose):

createWindow:

let { w, h, x, y, isMaximized } = getSavedSizeObject();
sizeTracker.setAll(w, h, x, y, isMaximized);
window.create(w, h, x, y); 
if (isMaximized) window.maximize();
window.show();

windowResize:

if (window.isMaximized) {
sizeTracker.setIsMaximized(true);
} else {
sizeTracker.setAll(w, h, x, y, false);
}

saveSize:

let { w, h, x, y, isMaximized } = sizeTracker.get(); 
saveSizeObject(w, h, x, y, isMaximized);

Note: sizeTracker is nothing but a simple in memory representation that tracks the size. Implicitly, the last window to quit wins. All the above points should be solved by adaptation of this pseudo code. And it will comply with the windows convention (and what one would naturally expect from any well behaving application). Should fit well with general Linux desktop managers as well.

If for whatever reason, a platform with weird conventions (perhaps the Mac? I have no idea) requires different handling, they can very well be hooked in the above pseudo code.

[bpasero]

@prasannavl I am not entirely convinced that the one issue is the same as the other. your issue talks about the fact that when you maximize a window from a certain size and then restart and restore, the previous size is not restored. I see this as an actual bug we should fix eventually.

The other point is about how new windows should be sized when you open them. I am not sure there is a solution that makes everyone happy. Yes, you could just pick the window size of the window that is the last active one, but from a UX perspective we decided not to create a window with the exact same dimensions because it can make it hard to actually notice that you have 2 windows open now. That is why we decide to fall back to the default size and you will notice that any further window you open from that point will cascade the window a little bit so that they are not exactly overlapping.

Now, you could also argue that maybe the window that opens should inherit a size that was associated with that folder when you previously opened it. Imagine we would remember each window dimensions for each folder opened and restore it if you ever open that folder again. Still, this might not fix the UX issue of overlapping windows.

I would be open to discuss other solutions but I would think that discussion should happen in another work item.

[prasannavl]

@bpasero The problem you mention can be solved this way, in a manner to keep everyone reasonably happy until more advanced configurations are added (if at all worth going through the trouble, which I don't think it is if the below can be implemented).

If its the first window opened by the application, use the same size.
If it is indeed a new one, cascade x, and y a bit. Now in order to do this, first check x + width, and y + height to make sure its not outside bounds of the visible screen. If it is, reduce the cascade values by half and try again, until its either zero, or succeeds. If all fails, now do the same thing again, with negative cascades as it approaches zero again.

The nifty little trick here, will be that, don't use the sizeTracker.setAll pseudo code above on window creation when its a non-first window. It will however work during resizes. So, the cool thing is, now the user size will always be respected, even though new windows cascade.

The new window's locations never gets saved. But the moment a user manually touches the window size, (by resize, movement etc), it gets saved as the new size.

[prasannavl]

PS: You could also very well, just let the platform's window manager handle the secondary window positions, by ignoring the x and y completely. Windows should handle the cascading on its own (Win32 should, but not sure if electron overrides it) I would consider that as a first stage to the solution.

Aside: Isn't that how "Windows" was historically named? It managed "windows" before all the OS intricacies came into play. Let's just get out of the way and let it do what it does best! ;)

[bpasero]

I am quite sure that the framework we use (Electron) on Windows does not provide any functionality to position the window in a clever way, but I can try again.

[prasannavl]

@bpasero While I'm not highly familiar with electron at the moment, I do know enough to agree that it doesn't provide any clever positioning. But what I was pointing at was that, does electron let the platform manager natively handle its position, or does it override the native functionality and thereby dum it down?

If its the former, then should be easy or I'm afraid the logic that I mentioned using the cascade, or similar has to be implemented. But considering the fact that you already do cascade it, can't we just use the same cascade logic that you already do, but just with the saved size instead of the default fallback size?

[regs01]

I just wanted to say exactly same. It's been pretty common in Windows to cascade windows. I was saying use same size, but i didn't say anything about same position, right because of cascading.

So there is a logic that could work flawlessly

1. First instance should open with saved size, saved position and saved state (maximized/restored).
2. Second instanced should only utilize saved size, but not position and state. If it's not possible to cascade it, then just use random position. State, though, is debatable. Some might would prefer all instances maximized.

[bpasero]

Allright, let me update the issue to reflect the discussion.

[regs01]

Most annoying thing about this problem is that it saves default window size every time you open second window. So basically those who are using multiple windows just stuck in a little window.

[bpasero]

Configuring window.newWindowDimensions helps in that case

[regs01]

window.newWindowDimensions helps to launch in previously stored size. But if it was maximized, then window size gets lost and resets to default.

[tgdn]

Doing something similar to what electron-window-state does is probably the intended behaviour here

[adonig]

Here is a workaround for those who still suffer. Don't maximise the window by clicking the "maximise" button. Just drag the window borders to the borders of the screen so the window fills the whole screen. Thereafter it stores the size on close and launches maximised.

EDIT: Ok, sorry, This only works one time. The next time you start vscode it isn't maximised again.

EDIT2: Linux users can try this workaround.

[kocicmickey]

This bug accidentally saved my butt when I just started to use VS Code and accidentally made it full-screen. I couldn't figure out a way to exit full-screen mode, but when I shut down VS Code and restarted it, it was back to windowed. That helped me greatly because I can't find information on how to exit full screen using VS Code.

[rakkarage]

everyone on windows and linux is losing window size on maximize for 4 years?

[prasannavl]

@kocicmickey - I probably wouldn't save full screen state anyway. So, even if this bug didn't exist, in the context of a text editor - I wouldn't design it with restoring full screen state unless explicitly configured so. But it's probably something to keep in mind whenever this thing gets fixed :)

@rakkarage - Yup. Probably, 2 years on Windows, and 2 years on Linux for me.

Unfortunately, while it clearly affects so many so widely, it's so minor a headache (resolvable through a 1 second effort), no one has taken it serious enough to step up to provide a PR yet (including myself, as I have just scripted it to a percent size of the screen so it doesn't affect me so much). That being said, I do hope that someone from the community steps up to fix it.

PS. As an aside, I think the whole window.newWindowDimensions is an unnecessary feature that the team gotten itself into, complicating startup things. I think redoing the startup workflow around fixing this would have kept things simple, and saved from yet another config property that probably wouldn't be need to be used in the first place in most cases, if this worked as indicated in the comments above. (The only real use case I'd see then, would be automation, which could be scripted anyway). So, overall I think vscode could have just done without window.newWindowDimensions and instead focusing that effort around this -- So far it has just led to more bugs and maintenance around that -- But now that this has been done, I'd assume fixing this too now probably involves having an "auto" option for it, which does the workflow as above, eventually turning this into the default option.

[rakkarage]

another workaround is to use devilspie2.lua or something to resize window when it starts

if (get_window_name()=="Visual Studio Code - Insiders") then unmaximize(); set_window_geometry(160, 90, 1600, 900); end

[bpasero]

Electron 4 introduced a new method BrowserWindow.getNormalBounds() that allows to ask the window for its bounds in non-maximized state. I pushed a change to use this method on Linux and Windows such as when you restore the window, you will get those bounds returned.

[regs01]

Did it go into June 2019 update?

[bpasero]

No, July.
This issue has already been fixed in our insiders version but not yet released to the stable version. To benefit from the fix, you can give our preview releases a try from: https://code.visualstudio.com/insiders/

[bpasero]

Verification: verify that the "normal" bounds of a window are persisted, via

• be on Windows
• position the window (not maximized) somewhere
• maximize window
• close
• start
• the window should opened maximized
• now restore the window (click restore button in title)
• the window should now have the size and position where you left it before