Configuring nw.Window open with show:false and load timeout behavior
0 reputation · 21 May 2026, 21:09 UTC
0 reputation · 21 May 2026, 21:09 UTC
When opening a window with nw.Window.open(url, {show:false}, callback) the application wants to guarantee that the window is destroyed if the page does not finish loading within a configurable time interval, preventing hidden windows from staying alive and keeping associated Node.js timers, streams or child processes running.
NW.js does not expose a native load‑timeout option for nw.Window.open, so developers must race a setTimeout against the loaded event and decide whether to invoke win.close(true) (force close, skipping the close event) or to let the normal close event fire so that any cancellation logic placed in a close handler runs. It is also unclear whether the close event is guaranteed to be emitted after a forced close, and how to ensure that Node.js resources tied to that window’s context are cleaned up regardless of the close path taken.
What is the recommended way to combine a load timeout with the window’s close event so that cleanup code runs exactly once, and should the timeout path use win.close(true) or rely on the default close handling?
let cleaned = false
win.on('loaded', () => {
clearTimeout(timeoutId)
})
timeoutId = setTimeout(() => {
if (!cleaned) {
win.close() // preserves close event; use win.close(true) only if manual cleanup already handled
}
}, LOAD_TIMEOUT_MS)
win.on('close', () => {
if (!cleaned) {
cleaned = true
// Node.js resource cleanup: clear timers, streams, child processes
}
})
Assumption: The target NW.js major version supports the loaded event pattern as documented for the 0.32 series; earlier or later versions may differ. Uncertainty: Without testing the exact version, it cannot be guaranteed that win.close(true) suppresses the close event or that Node.js timers started in the window context are terminated automatically.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.