[Bug] Cannot minimize or maximize VSCode on Windows
codeAbinash opened this issue · 20 comments
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
Cannot minimize or maximize window.
Expected Behavior
Minimizing or maximizing window should work.
Steps To Reproduce
Vibrancy Continued
v1.1.29
Environment
- OS: Windows 11
- VSCode: 1.87.2
- Extension: Vibrancy Continued v1.1.29
- Theme: One Dark Pro DarkerAnything else?
Rounded corners are also not available in window.
Known issue due to breaking Electron 27 changes as mentioned in the description, currently no workaround besides downgrading VSCode to 1.85.2, will keep this issue open for future updates.
Even after downgrading VSCode to 1.85.2 the minimize/max- functionality still doesn't work!
Same error, any solution?
I've uninstalled vibrancy continued but still can't use the maximize and minimize button, any fixes?
I've uninstalled vibrancy continued but still can't use the maximize and minimize button, any fixes?
Install it again, run vscode as administrator, press F1 and click "Disable Vibrancy", and uninstall it.
Same error on v1.89.1
I've uninstalled vibrancy continued but still can't use the maximize and minimize button, any fixes?
Install it again, run vscode as administrator, press F1 and click "Disable Vibrancy", and uninstall it.
Life saver! This has worked for me!
The same thing (1.89.1)
Everyone on Windows with VSCode 1.86.0 and newer is currently experiencing this issue, no need to +1 unless you have something to add to the discussion.
As a reminder, Vibrancy needs to be reloaded after downgrading VSCode as mentioned earlier by another user.
I am using FancyWM, and it seems like whatever bug is causing this is also causing FancyWM to not work. It cannot resize or move vscode.
Everyone on Windows with VSCode 1.86.0 and newer is currently experiencing this issue, no need to +1 unless you have something to add to the discussion.
As a reminder, Vibrancy needs to be reloaded after downgrading VSCode as mentioned earlier by another user.
As illixion said, EVERYONE is currently experiencing this issue, so please do NOT comment when you cannot provide any information to help solve the problem.
When you comment, everyone who subscribed this issue will get a notification, if your comment can't help everyone, it will cause unnecessary disturbance.
How can I solve this problem so that vibrancy works but does not have this problem?
You need to downgrade to VSCode 1.85.2, which is clearly mentioned in the first reply in this thread and at the very top of Vibrancy’s description.
Guys, after I pressed F1 and type "Disable Vibrancy" I uninstalled the extention, and I reinstalled the vs code, it worked
I've uninstalled vibrancy continued but still can't use the maximize and minimize button, any fixes?
Install it again, run vscode as administrator, press F1 and click "Disable Vibrancy", and uninstall it.
Thanks a bunch brother. Saved my life
I've uninstalled vibrancy continued but still can't use the maximize and minimize button, any fixes?
Install it again, run vscode as administrator, press F1 and click "Disable Vibrancy", and uninstall it.
It Worked very well !!
It's been 7 updates and this issue is still not fixed, if someone knows how minimize and maximize functions works, pls answers to this comment, so we can try to fix it and make a pull request
It's been 7 updates and this issue is still not fixed, if someone knows how minimize and maximize functions works, pls answers to this comment, so we can try to fix it and make a pull request
It's indeed annoying. I just swiched to windows for work and being unable to snap VSCode is slowly getting me.
I quickly searched but cannot find anything related to window resizing in Electron 27 changelog
But its probably due to the fact that this plugin overrides the default behaviour of moving and resizing.
Line 33 : vscode-vibrancy-continued/blob/main/runtime/win10refresh.js :
/**
* Unfortunately, we have to re-implement moving and resizing.
* Enabling vibrancy slows down the window's event handling loop to the
* point building a mouse event backlog. If you just handle these events
* in the backlog without taking the time difference into consideration,
* you end up with visible movement lag.
* We tried pairing 'will-move' with 'move', but Electron actually sends the
* 'move' events _before_ Windows actually commits to the operation. There's
* likely some queuing going on that's getting backed up. This is not the case
* with 'will-resize' and 'resize', which need to use the default behavior
* for compatibility with soft DPI scaling.
* The ideal rate of moving and resizing is based on the vertical sync
* rate: if your display is only fully updating at 120 Hz, we shouldn't
* be attempting to reset positions or sizes any faster than 120 Hz.
* If we were doing this in a browser context, we would just use
* requestAnimationFrame and call it a day. But we're not inside of a
* browser context here, so we have to resort to clever hacks.
* This VerticalRefreshRateContext maps a point in screen space to the
* vertical sync rate of the display(s) actually handing that point.
* It handles multiple displays with varying vertical sync rates,
* and changes to the display configuration while this process is running.
*/
Is This workaround still necessarry ? It seems janky at best.