一个Electron的设计缺陷及应对方案

时间:2024-02-21 20:18:59

当你想实现阻止Electron窗口关闭,并弹出询问对话框,提示用户:“文章尚未保存,是否要关闭窗口”这类业务时,那么你99%会碰到这个BUG:

https://github.com/electron/electron/issues/24994

这是我在去年8月份发现的BUG,Electron的作者也已经确认了这个BUG,但遗憾的是现在还没有修复。下面我们就聊聊这个问题,以及应对这个问题的方案。

问题描述

要阻止窗口关闭,必须在窗口的关闭事件中,执行preventDefault操作才行,如下代码所示:

win.on("close", (e) => {
  e.preventDefault();
});

然而这个preventDefault的操作,必须同步调用才能生效,所有异步调用preventDefault的操作都没有任何效果,代码如下所示:

win.on("close", async (e) => {
 console.log("win close");
 await new Promise((resolve) => setTimeout(resolve, 1000));
 e.preventDefault();  //没有任何作用
});

上述代码中的preventDefault操作就不会起任何作用。这就带来了一个业务问题:我们往往在询问用户并获得用户的允可后才会阻止窗口关闭,比如:“文章尚未保存,您确认关闭窗口吗?”开发者无法在这种异步的询问通知前执行preventDefault操作,就无法正确的阻止窗口关闭。

可能你会想到用dialog模块的showMessageBoxSync方法来完成这个询问操作,如下代码所示:

win.webContents.on('will-prevent-unload', event => {
    let choice = dialog.showMessageBoxSync({
      title:'do you want to close',
      buttons:['cancel','yes']
    });
    if(choice === 1)  event.preventDefault();
    //...
  })

没错showMessageBoxSync是一个同步方法,但这也会导致整个主进程的JavaScript线程阻塞,你预期在未来发生的所有事件,以及这些事件的回调方法,都不会再执行了(想想看,你的setInterval的回调方法不会定时执行的结果)。

直到用户关闭showMessageBoxSync方法打开的窗口,主进程的JavaScript线程才会恢复,如果用户永远不做出这个选择,那么整个JavaScript线程就会一直等待下去。

应对方案

为了解决这个问题,我们可以通过额外的哨兵变量来处理,代码如下所示:

//import { app, BrowserWindow, dialog } from "electron";
let winCanBeClosedFlag = false;
win.on("close", async (e) => {
  if (!winCanBeClosedFlag) {
    e.preventDefault();
    let choice = await dialog.showMessageBox(win, {
      title: "do you want to close",
      message: "你确定要关闭窗口吗?",
      buttons: ["否", "是"],
    });
    if (choice.response == 1) {
      winCanBeClosedFlag = true;
      win.close();
      return;
    }
  }
  winCanBeClosedFlag = false;
});

默认情况下winCanBeClosedFlag 这个变量的值是false,即不允许用户关闭窗口(此处的preventDefault是同步操作),当我们询问过用户,并且用户做出了确认关闭的选择后,这个变量才会被设置为true。此时立即调用窗口的close方法,这个窗口的close事件被再次触发,因为winCanBeClosedFlag 变量已经被置为true了,所以不会执行preventDefault操作,窗口被正常关闭。

窗口被关闭的同时winCanBeClosedFlag变量又被置为false,以备下一次用户的操作。