summaryrefslogtreecommitdiffstats
path: root/packages/meshbay-client/src/main.js
diff options
context:
space:
mode:
Diffstat (limited to 'packages/meshbay-client/src/main.js')
-rw-r--r--packages/meshbay-client/src/main.js10
1 files changed, 10 insertions, 0 deletions
diff --git a/packages/meshbay-client/src/main.js b/packages/meshbay-client/src/main.js
index de8de8f..27c81b8 100644
--- a/packages/meshbay-client/src/main.js
+++ b/packages/meshbay-client/src/main.js
@@ -453,6 +453,16 @@ function createWindow() {
});
win.once('ready-to-show', () => win.show());
+ // Some Wayland compositors (observed under GNOME/Mutter on a VM with a
+ // virtio-gpu device whose command-buffer creation fails) never schedule a
+ // first paint for a surface that isn't mapped yet — but Electron won't map
+ // it (show()) until `ready-to-show` fires, which waits for that paint. The
+ // two conditions deadlock the window invisible forever. This bounded
+ // fallback breaks the cycle. Guarded on isVisible(): show() also raises
+ // and refocuses an already-visible window, so once the event has fired
+ // normally (real GPU/X11 hosts, well under 2s) this must stay a no-op
+ // rather than yank focus back from whatever the person switched to.
+ setTimeout(() => { if (!win.isDestroyed() && !win.isVisible()) win.show(); }, 2000);
// The hub must never become the document origin. Anything that would navigate
// away from the packaged interface is refused, and an external link opens in