electron: Drag-Drop making element go black and crash
- Electron version: 2.0.0
- Operating system: Fedora Linux 28 - 4.16.5-300.fc28.x86_64
- Hardware: Intel HD Graphics 4400
- Last known working Electron version:
1.8.6 (but flashes black at the beginning of the drag)
Message on debug 1.8.6:
[6956:0503/113418.226485:ERROR:buffer_manager.cc(453)] [.DisplayCompositor-0x345f2e791700]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
Expected behavior
Drag and drop without crash the Electron, and the element not turn to black.
Actual behavior
When drag an element it turn black, freeze Electron and the black element stay on screen even through other programs. No messages on debug, just freeze.
How to reproduce
Start any project with a button with attribute draggable=“true”. Start dragging it, done.
ckerr edit: duplicate bug https://github.com/electron/electron/issues/13384 has a repro repo
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 13
- Comments: 36 (7 by maintainers)
Commits related to this issue
- Disabled GPU rendering as a workaround to a rendering crash bug (https://github.com/electron/electron/issues/12820) — committed to WeilonYing/LANLine by WeilonYing 6 years ago
- [MSG01] Implement broadcast feature (#3) * Add initial draft of local sqlite db schema and JSON message format * [Teresa] Setup frontend with SASS * [Teresa] Sidebar Frontend completed * Swi... — committed to WeilonYing/LANLine by WeilonYing 6 years ago
@codebytere @sofianguy Sorry to bug you, but is there any chance we could get a status update on this issue? I appreciate the labels and the “i’ll 👀 this soon”, but after five months even just something like “we have no idea, you’re on your own” would be a helpful communication. Thanks for your help!
@anchepiece Awesome. Thanks, I missed that. Just tested this workaround and it works. Also thanks to @bpasero.
Finally, my CPU gets a break from software rendering 💃
Turns out this is a Heisenbug, as I’ve accidentally found another workaround that makes no sense.
I have no idea why this prevents the issue from happening, but it’s semi-maddening.
I’ve taken a short screencast to show the bug with
electron --default, with and without the above workaround:https://vimeo.com/283985893
Because I want to make sure this is actionable for everyone, you can apply this workaround indefinitely by adding the code to
/etc/environment. You may (?) need to log out and log back in. Hell, you might even need to restart – I don’t really remember. For me, that looked something like this:@christianbundy Thank you for finding a workaround! I added this code to run on only Linux in my project and drag-drop works!
app.disableHardwareAcceleration()@dev-zetta I encountered a similar issue and resolved it by redirecting (stdout) output as hinted above by @bpasero
Can you try launching using something like
$ nohup yourappOr if you want to capture the output$ nohup yourapp < /dev/null > nohup.out 2> nohup.err &Electron 3.0.0-beta
Still not fixed. Flag
--disable-gpufixes the issue, albeit it does not fix the problem. There might be some projects out there that may need hardware acceleration.yep, i’ll 👀 this soon!
Backtrace from when the program is in a frozen state after drag-and-drop:
@christianbundy if I had to guess then this has something to do with how stdout is handled in the one case vs. the other case. I can reproduce the issue of seeing this message popping up from a simple fiddle with a draggable element:
[31176:0919/100345.056256:ERROR:buffer_manager.cc(453)] [.DisplayCompositor-0x145e13148800]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL commandPossibly, there is a crash while doing the DND operation when trying to write this message to stdout and this causes the freeze.
Output for
$ sudo lspci -v | sed -n '/VGA/,/^$/p'PS: what is interesting is that I can reproduce the error message while dragging even with 1.7.x already, so it seems it has always been there. I am quite sure, fixing that error message to output would fix the freeze.
Hi. I’m having similar issues on apps using eletron (crashe on drag’n’drop). In my case, it’s with VSCode and Slack desktop client.
I’m using archlinux with xorg & i3. Same issues happen when running sway instead of xorg. GPU is Inter Graphics (cpu integrated). @christianbundy’s workaround doesn’t work for me.
If I start my slack or vscode with the
--disable-gpuit doesn’t crash anymore. BUT it doesn’t always fix drag’n’drop either. Some app sessions will work perfectly. But for some others, d’n’d will not make the app crash but will have no effect.Also, without the --disable-gpu, VSCode crashes sometimes when I unlock my screen (i3-lock).
I guess it’s a problem only occuring for some people with specific GPUs.
@christianbundy Yes works fine with --disable-gpu.
Workaround:
--disable-gpuI found this suggestion here: https://github.com/electron/electron/issues/4380#issuecomment-18844866
@leotada Can you verify that
electron --disable-gpuworks for you as well?Additional notes
--disable-gpu-blacklistdoesn’t fix the issue--type=gpu-process--no-sandbox--supports-dual-gpus=false--gpu-driver-bug-workarounds=1,9,27,70,84--disable-gl-extensions=GL_KHR_blend_equation_advancedGL_KHR_blend_equation_advanced_coherent--disable-accelerated-video-decode--gpu-vendor-id=0x8086--gpu-device-id=0x1616--gpu-driver-vendor--gpu-driver-version--gpu-driver-date--service-request-channel-token=0EB803B34379058862EC3D63D17A989E--type=renderer--no-sandbox--service-pipe-token=7A0DA93E3DA90C3F2E2E91228251969D--lang=en-US--app-path=/home/christianbundy/src/electron-test/node_modules/electron/dist/resources/default_app.asar--node-integration=true--node-integration-in-worker--webview-tag=true--no-sandbox--background-color=#FFFFFF--context-id=2--enable-pinch--num-raster-threads=2--enable-main-frame-before-activation--content-image-texture-target=0,0,3553;0,1,3553;0,2,3553;0,3,3553;0,4,3553;0,5,3553;0,6,3553;0,7,3553;0,8,3553;0,9,3553;0,10,3553;0,11,3553;0,12,3553;0,13,3553;0,14,3553;0,15,3553;0,16,3553;0,17,3553;1,0,3553;1,1,3553;1,2,3553;1,3,3553;1,4,3553;1,5,3553;1,6,3553;1,7,3553;1,8,3553;1,9,3553;1,10,3553;1,11,3553;1,12,3553;1,13,3553;1,14,3553;1,15,3553;1,16,3553;1,17,3553;2,0,3553;2,1,3553;2,2,3553;2,3,3553;2,4,3553;2,5,3553;2,6,3553;2,7,3553;2,8,3553;2,9,3553;2,10,3553;2,11,3553;2,12,3553;2,13,3553;2,14,3553;2,15,3553;2,16,3553;2,17,3553;3,0,3553;3,1,3553;3,2,3553;3,3,3553;3,4,3553;3,5,3553;3,6,3553;3,7,3553;3,8,3553;3,9,3553;3,10,3553;3,11,3553;3,12,3553;3,13,3553;3,14,3553;3,15,3553;3,16,3553;3,17,3553;4,0,3553;4,1,3553;4,2,3553;4,3,3553;4,4,3553;4,5,3553;4,6,3553;4,7,3553;4,8,3553;4,9,3553;4,10,3553;4,11,3553;4,12,3553;4,13,3553;4,14,3553;4,15,3553;4,16,3553;4,17,3553--disable-accelerated-video-decode--enable-gpu-async-worker-context--service-request-channel-token=7A0DA93E3DA90C3F2E2E91228251969D--renderer-client-id=4--shared-files=v8_natNot completely sure how to further debug, but at least we can pin it down to the GPU.
Reproduction steps:
Expected (and working in v1.8.4):
Actual (v2.0.0):
Nope, I think this is fixed in Electron 11.