Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App crashes with "Object has been destroyed" error #156

Open
thecodrr opened this issue Jun 22, 2023 · 4 comments · May be fixed by #197
Open

App crashes with "Object has been destroyed" error #156

thecodrr opened this issue Jun 22, 2023 · 4 comments · May be fixed by #197

Comments

@thecodrr
Copy link

thecodrr commented Jun 22, 2023

I believe it is coming from here due to win being destroyed:

if (key.startsWith(`${win.webContents.id}-`)) {

Here's the full error:

image

@jsonnull
Copy link
Owner

jsonnull commented Jul 6, 2023

Hey @thecodrr, can you provide more information about when the error occurs?

I'm confident I have a fix, but I want to be sure I understand the root cause before I patch it.

@thecodrr
Copy link
Author

thecodrr commented Jul 6, 2023

@jsonnull this occurs on closing the window.

@Galkon
Copy link

Galkon commented Feb 27, 2024

Did you figure out a solution? Running into this as well.

TypeError: Object has been destroyed
    at Q.detachWindow (/Users/joshualipson/GitHub/medal/node_modules/electron-trpc/dist/main.cjs:1:3867)
    at WebContents.<anonymous> (/Users/joshualipson/GitHub/medal/node_modules/electron-trpc/dist/main.cjs:1:4021)
    at WebContents.emit (node:events:529:35)

@dguenther
Copy link

For us, this was happening because our app explicitly calls destroy on a BrowserWindow.

Reproduction

You can reproduce it by calling win.destroy() in the ready event handler in the example here:

createIPCHandler({ router, windows: [win] });

For example:

  setTimeout(() => {
    win.destroy()
  }, 5000)

I haven't found a workaround other than to avoid calling destroy().

Root Cause

detachWindow is called in win.webContents.on('destroyed', () => {:

detachWindow then accesses win.webContents.id, which throws an error if the window is already destroyed:

this.#cleanUpSubscriptions({ webContentsId: win.webContents.id });

It also accesses win.id, which used to throw an error, but now does not: electron/electron#38170

Apparently the destroyed event doesn't guarantee that the window hasn't yet been destroyed.

Potential Fix

The easiest would probably be to capture win.webContents.id earlier in attachSubscriptionCleanupHandlers and pass it to detachWindow:

#attachSubscriptionCleanupHandlers(win: BrowserWindow) {
win.webContents.on('did-start-navigation', ({ frame }) => {
debug(
'Handling webContents `did-start-navigation` event',
`webContentsId: ${win.webContents.id}`,
`frameRoutingId: ${frame.routingId}`
);
this.#cleanUpSubscriptions({
webContentsId: win.webContents.id,
frameRoutingId: frame.routingId,
});
});
win.webContents.on('destroyed', () => {
debug('Handling webContents `destroyed` event');
this.detachWindow(win);
});
}
}

I'll put up a PR with this fix, but I'm definitely open to alternatives!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants