-
Notifications
You must be signed in to change notification settings - Fork 16.4k
Description
Preflight Checklist
- I have read the Contributing Guidelines for this project.
- I agree to follow the Code of Conduct that this project adheres to.
- I have searched the issue tracker for an issue that matches the one I want to file, without success.
Issue Details
- Electron Version: 5.0.8
- Operating System: Windows 10 (1809)
- Last Known Working Electron version: 3.1.12
Expected Behavior
Calling the asynchronous fs APIs should work in the renderer process in the same way that it works in the main process.
Actual Behavior
Calls to the asynchronous fs APIs in the renderer process will randomly fail. No exception is thrown, rather, it seems like the callback is never called when using the old asynchronous API and the awaited promise will never complete when using the newer fs.promises API. The synchronous API seems to work consistently.
I have observed this error with code like:
const fs = require("fs");
// Sometimes this callback will never be called
fs.stat("C:\\", () => {});
// Sometimes this will await forever
await fs.promises.stat("C:\\");
// This always seems to work
fs.statSync("C:\\");
While I use stat
in the example above, I've also observed it with readFile
and writeFile
. I've also observed the issue on a variety of paths, not just "C:\". The issue seems to go away if I refresh the browser window. So I've refactored my application in the short term to refresh the browser window after initial load. I've added a branch to renderer.js similar to:
const electron = require("electron");
if (electron.remote.getCurrentWindow().hasReloaded) {
// Run renderer logic
} else {
electron.ipcRenderer.send("needs-reload");
}
Then in the main process I do:
const electron = require("electron");
let browserWindow;
electron.ipcMain.on(
"needs-reload",
() => {
browserWindow.hasReloaded = true;
browserWindow.reload();
}
);
// Run main logic, including creating browserWindow.
To Reproduce
See my notes above, let me know if you'd like more information.
Additional Information
It looks like this issue in nodejs is also observing the problem nodejs/node#14889.