voideditor
[Bug] Freezes with light themes
VSCode Version: 1.99.30034 Void Version: 1.3.10 Commit: 906502f6600146442d41bc314c2dd011c686941f Date: 2025-05-16T20:35:23.913Z Electron: 34.3.2 ElectronBuildId: undefined Chromium: 132.0.6834.210 Node.js: 20.18.3 V8: 13.2.152.41-electron.0 OS: Windows_NT x64 10.0.26100
The UI freezes a few seconds after starting. It only seems to freeze with light themes. If you quickly switch to a dark theme, it won't freeze. If you switch to a light theme, it will freeze.
Hi @azenin—when you say “freezes,” do the input fields on the onboarding/settings page stop responding? Trying to confirm if this matches the symptoms in issue #418, so any extra details would help.
Yes, it matches #418 and #416. The entire UI becomes unresponsive except for the close buttons in the top right corner. If you uninstall the program and then reinstall version 1.99.30031, there is no problem until you restart. However, after you restart and update, the problem happens again because the program downloads updates automatically.
In my observation, the panel will turns completely white if we set a light theme, rendering it invisible. However, despite the visual glitch, the panel remains functional, allowing me to interact with it based on memory. I can still navigate through the settings and adjust the theme or switch to dark mode. Although this workaround resolves the issue temporarily, I believe the underlying cause is a bug that needs to be addressed.
got it, thanks for the feedback! assuming windows, could you please try to launch Void like this: "C:\Program Files\Void\void.exe" --disable-extensions to rule out a misbehaving theme/extension, and so if the freeze still happens pls try "C:\Program Files\Void\void.exe" --disable-gpu --disable-software-rasterizer as well (electron inherits chromium’s flag parser, so --disable-gpu disables hardware-accelerated compositing while --disable-software-rasterizer blocks the shader fallback); im wondering if either of the runs above stops the lock-up for you - just trying to pinpoint whether the issue lives in an extension, theme CSS, or the GPU rendering path..
I also removed all extensions and models.
The program still freezes when I run it with the flag --disable-extensions. Here's the console output:
[main 2025-05-23T03:27:00.325Z] update#setState idle
Void posthog metrics info: {
"distinctId": "37befef3-5ba7-4cd7-9fe6-36a610648eb7",
"properties": {
"commit": "906502f6600146442d41bc314c2dd011c686941f",
"vscodeVersion": "1.99.30034",
"voidVersion": "1.3.10",
"os": "windows",
"quality": "stable",
"distinctId": "37befef3-5ba7-4cd7-9fe6-36a610648eb7",
"distinctIdUser": "2bfaf541-2557-445d-88b1-b0b8c755425b",
"oldId": "NULL",
"isDevMode": false,
"platform": "win32",
"arch": "x64"
}
}
(node:7836) [DEP0168] DeprecationWarning: Uncaught N-API callback exception detected, please run node with option --force-node-api-uncaught-exceptions-policy=true to handle those exceptions properly.
(Use `void --trace-deprecation ...` to show where the warning was created)
(node:7836) [DEP0168] DeprecationWarning: Uncaught N-API callback exception detected, please run node with option --force-node-api-uncaught-exceptions-policy=true to handle those exceptions properly.
(node:7836) [DEP0168] DeprecationWarning: Uncaught N-API callback exception detected, please run node with option --force-node-api-uncaught-exceptions-policy=true to handle those exceptions properly.
[main 2025-05-23T03:27:05.691Z] update#setState checking for updates
updateState { type: 'checking for updates', explicit: false }
[main 2025-05-23T03:27:05.704Z] update#setState idle
For --disable-gpu --disable-software-rasterizer:
Warning: 'disable-software-rasterizer' is not in the list of known options, but still passed to Electron/Chromium.
[main 2025-05-23T03:28:38.830Z] update#setState idle
Void posthog metrics info: {
"distinctId": "37befef3-5ba7-4cd7-9fe6-36a610648eb7",
"properties": {
"commit": "906502f6600146442d41bc314c2dd011c686941f",
"vscodeVersion": "1.99.30034",
"voidVersion": "1.3.10",
"os": "windows",
"quality": "stable",
"distinctId": "37befef3-5ba7-4cd7-9fe6-36a610648eb7",
"distinctIdUser": "2bfaf541-2557-445d-88b1-b0b8c755425b",
"oldId": "NULL",
"isDevMode": false,
"platform": "win32",
"arch": "x64"
}
}
(node:20400) [DEP0168] DeprecationWarning: Uncaught N-API callback exception detected, please run node with option --force-node-api-uncaught-exceptions-policy=true to handle those exceptions properly.
(Use `void --trace-deprecation ...` to show where the warning was created)
(node:20400) [DEP0168] DeprecationWarning: Uncaught N-API callback exception detected, please run node with option --force-node-api-uncaught-exceptions-policy=true to handle those exceptions properly.
(node:20400) [DEP0168] DeprecationWarning: Uncaught N-API callback exception detected, please run node with option --force-node-api-uncaught-exceptions-policy=true to handle those exceptions properly.
[main 2025-05-23T03:28:44.098Z] update#setState checking for updates
updateState { type: 'checking for updates', explicit: false }
[main 2025-05-23T03:28:44.104Z] update#setState idle
So, it didn't help
got it - thanks - i think i have a potential fix - i.e. unblocking the os compositor that hangs on pure-white first frames (which is the root cause of the blank-screen-until-resize bug on both win and mac). given the broad impact, plan is to run cross-platform and multi-window tests, then submit a pr..
(you can fix this by resizing the window for now)
Thanks for looking into this @vrtnis, keep me posted if you find anything!
quick update.. the investigation has narrowed things down to the compositor itself
current diagnosis is still the same i.e., the os compositor stalls on the very first pure-white frame, so once a resize arrives, everything repaints normally.
mitigations explored (in windowImpl.ts): ±1 px jiggle, maximize- restore, blur/focus, transparent-tint splash, dark-then-light theme flip etc. on various platforms using voidbuilder... each reliably does force a repaint, confirming the theory although none eliminate the underlying stall.
this leads us to believe the root cause is upstream: behavior matches electron/electron #39959. the supposed "fix" in PR #40749 (shipped in 28.1.1 / 29-beta, noted again in the 30-series) still reproduces on 34.3.2, so either that patch regressed or a neighboring path slipped
temporary safety-net: start every window minimized; the first user maximize/restore triggers a repaint, so the UI appears unfrozen instantly. it works (for obvious reasons) but we’d rather not make users maximize-on-launch the long-term UX so not keen on this.
one option is to move to Electron 35/36 (has an Electron upgrade been considered at some point @andrewpareles ?); if the blank frame vanishes we can factor it into as one more reason to bump the runtime.
however, if it persists, can open a fresh Electron ticket referencing #39959 & #40749 with a minimal repro (transparent + hidden-title-bar window that starts on #FFFFFF).
~~Putting the following at the end of your preload.js (inside the application bundle) will provide a workaround for the bug. It's a clumsy hack but it fixes the issue (I can't believe so few people use light themes!?)~~
~~https://gist.github.com/justin-vt/dcf601e43de22a99f24a095ebd695f6f~~
~~(You may intiially get a warning from Void about its core being modified, but it can be muted)~~
~~Edit: This no longer works with the latest Void update - it seems to be due to some application integrity issue, since Void now crashes if you even add a comment to preload.js.~~
Edit # 2: Solved by placing this gist at the end of ./Resources/app/out/vs/code/electron-sandbox/workbench/workbench.js
(includes a bugfix that explicitly returns focus to the current selected element, to fix an issue with the sidebar losing focus)
Edit # 3: Updated the gist with another bugfix that fixes a problem when the editor is minimized or in the background a long time, and an issue with the command palette using focus
