socket.io connection event after disconnect event loses all browserWindow references #527

New Issue

claunia · 2026-01-29T16:41:59Z

claunia commented

2026-01-29 16:41:59 +00:00

Originally created by @MopsieX on GitHub (Jul 3, 2020).

Originally assigned to: @GregorBiswanger on GitHub.

Version: 9.31.1

Target: Windows 10

When the socket in main.js gets disconnected it deletes all the requires and then it will connect again. When the connection event fires again it reinitializes all of the requires however the windows[] and window variable aren't ever set in browserWindows.js. To fix it the main.js just needs to copy the references of all the windows before it deletes the require cache for browserWindows.js then after the browserWindows.js gets reinitialized/required the main.js needs to pass the windows to it.
Sorry for the bad explanation. I'm terrible at explaining things. If you have any questions or need clarification let me know.

Originally created by @MopsieX on GitHub (Jul 3, 2020). Originally assigned to: @GregorBiswanger on GitHub.    * **Version**: 9.31.1   * **Target**: Windows 10   When the socket in main.js gets disconnected it deletes all the requires and then it will connect again. When the connection event fires again it reinitializes all of the requires however the windows[] and window variable aren't ever set in browserWindows.js. To fix it the main.js just needs to copy the references of all the windows before it deletes the require cache for browserWindows.js then after the browserWindows.js gets reinitialized/required the main.js needs to pass the windows to it. Sorry for the bad explanation. I'm terrible at explaining things. If you have any questions or need clarification let me know.

claunia added the bug label 2026-01-29 16:42:00 +00:00

claunia closed this issue

2026-01-29 16:42:00 +00:00

claunia commented

2026-01-29 16:42:01 +00:00

@Velorien commented on GitHub (Jul 6, 2020):

This seems like a probable cause for #421

@Velorien commented on GitHub (Jul 6, 2020): This seems like a probable cause for #421

claunia commented

2026-01-29 16:42:02 +00:00

@MopsieX commented on GitHub (Jul 6, 2020):

This seems like a probable cause for #421

Yup you are correct. I get that same error message you get once it happens. Thanks for linking it and having a picture of the error in your bug report. I forgot to include a screenshot of the error message when the bug happens.
Hopefully 9.31.2 is released today with this fixed.

@MopsieX commented on GitHub (Jul 6, 2020): > > > This seems like a probable cause for #421 Yup you are correct. I get that same error message you get once it happens. Thanks for linking it and having a picture of the error in your bug report. I forgot to include a screenshot of the error message when the bug happens. Hopefully 9.31.2 is released today with this fixed.

claunia commented

2026-01-29 16:42:02 +00:00

@MopsieX commented on GitHub (Jul 6, 2020):

@GregorBiswanger @Velorien Unfortunately this isn't fixed in the newest version so the problem is still here.

@MopsieX commented on GitHub (Jul 6, 2020): @GregorBiswanger @Velorien Unfortunately this isn't fixed in the newest version so the problem is still here.

claunia commented

2026-01-29 16:42:03 +00:00

@GregorBiswanger commented on GitHub (Jul 6, 2020):

Hey Community, we have released version 9.31.2 with the electron-builder fix! In addition, I have improved the socket problems again and updated to Electron 9.0.5.

Please remove in your obj folder the Host and Desktop folder and try again with the newest Electron.NET API and CLI in 9.31.2.

@GregorBiswanger commented on GitHub (Jul 6, 2020): Hey Community, we have released version 9.31.2 with the electron-builder fix! In addition, I have improved the socket problems again and updated to Electron 9.0.5. Please remove in your `obj` folder the `Host` and `Desktop` folder and try again with the newest Electron.NET API and CLI in 9.31.2.

claunia commented

2026-01-29 16:42:03 +00:00

@MopsieX commented on GitHub (Jul 6, 2020):

Thanks I will do that!

@MopsieX commented on GitHub (Jul 6, 2020): Thanks I will do that!

claunia commented

2026-01-29 16:42:03 +00:00

@MopsieX commented on GitHub (Jul 6, 2020):

@GregorBiswanger It disconnects less often now but on reconnect the property windows never gets populated with the existing windows which means the app needs to be restarted.

@MopsieX commented on GitHub (Jul 6, 2020): @GregorBiswanger It disconnects less often now but on reconnect the property [windows](https://github.com/ElectronNET/Electron.NET/blob/master/ElectronNET.Host/api/browserWindows.js#L4) never gets populated with the existing windows which means the app needs to be restarted.

claunia commented

2026-01-29 16:42:04 +00:00

@MopsieX commented on GitHub (Jul 6, 2020):

I think I fixed the bug in the source. I'm testing it now but I need to wait for a disconnect.

@MopsieX commented on GitHub (Jul 6, 2020): I think I fixed the bug in the source. I'm testing it now but I need to wait for a disconnect.

claunia commented

2026-01-29 16:42:04 +00:00

@MopsieX commented on GitHub (Jul 7, 2020):

Never mind I was wrong. It's a lot harder to fix than I thought it was. I've learned a lot about how Electron.Net works so tomorrow I should have more luck fixing it.

@MopsieX commented on GitHub (Jul 7, 2020): Never mind I was wrong. It's a lot harder to fix than I thought it was. I've learned a lot about how Electron.Net works so tomorrow I should have more luck fixing it.

claunia commented

2026-01-29 16:42:04 +00:00

@freosc commented on GitHub (Jul 13, 2020):

I added
socket.removeAllListeners();
to the socket.on('disconnect', function (reason) function in main.js
But that doesn't seem to help.
After 10 socket disconnect/reconnect I get:

16:36:22.056 > stdout: Socket Disconnect! ping timeout
16:36:22.058 > Got disconnect! Reason: transport close
16:36:25.125 > ASP.NET Core Application connected... global.electronsocket ry2ZzmrkaKieYTSaAAAJ 2020-07-13T14:36:25.125Z
16:36:25.141 > (node:33040) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 window-all-closed listeners added to [App]. Use emitter.setMaxListeners() to increase limit
16:36:25.142 > stdout: BridgeConnector connected!

I'm not sure if it's related to the removeAllListeners or not. It's hard to debug this code and reproduce 10 disconnects.

@freosc commented on GitHub (Jul 13, 2020): I added `socket.removeAllListeners(); ` to the socket.on('disconnect', function (reason) function in main.js But that doesn't seem to help. After 10 socket disconnect/reconnect I get: > 16:36:22.056 > stdout: Socket Disconnect! ping timeout > 16:36:22.058 > Got disconnect! Reason: transport close > 16:36:25.125 > ASP.NET Core Application connected... global.electronsocket ry2ZzmrkaKieYTSaAAAJ 2020-07-13T14:36:25.125Z > 16:36:25.141 > (node:33040) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 window-all-closed listeners added to [App]. Use emitter.setMaxListeners() to increase limit > 16:36:25.142 > stdout: BridgeConnector connected! I'm not sure if it's related to the removeAllListeners or not. It's hard to debug this code and reproduce 10 disconnects.

claunia commented

2026-01-29 16:42:05 +00:00

@HermesNew commented on GitHub (Jul 16, 2020):

We also encountered the same issue, this issue is more urgent.

@HermesNew commented on GitHub (Jul 16, 2020): We also encountered the same issue, this issue is more urgent.

claunia commented

2026-01-29 16:42:05 +00:00

@HermesNew commented on GitHub (Jul 16, 2020):

@MopsieX Do you fixed the bug?

@HermesNew commented on GitHub (Jul 16, 2020): @MopsieX Do you fixed the bug?

claunia commented

2026-01-29 16:42:05 +00:00

@HermesNew commented on GitHub (Jul 21, 2020):

@GregorBiswanger How long will this bug be fixed?

@HermesNew commented on GitHub (Jul 21, 2020): @GregorBiswanger How long will this bug be fixed?

claunia commented

2026-01-29 16:42:06 +00:00

@MopsieX commented on GitHub (Jul 24, 2020):

I haven't fixed it. I got super busy and haven't had more time to try to fix it.

@MopsieX commented on GitHub (Jul 24, 2020): I haven't fixed it. I got super busy and haven't had more time to try to fix it.

claunia commented

2026-01-29 16:42:06 +00:00

@rakista112 commented on GitHub (Jul 30, 2020):

@MopsieX could you share your plan with us so we can help?

@rakista112 commented on GitHub (Jul 30, 2020): @MopsieX could you share your plan with us so we can help?

claunia commented

2026-01-29 16:42:06 +00:00

@danatcofo commented on GitHub (Oct 5, 2020):

@MopsieX et all... found a way to externally kill the ports and force a reconnect.

http://www.nirsoft.net/utils/cports.html

My first pass on a fix is basically to do a connect once method. basically replacing startSocketApiBridge() with the following code in main.js. This doesn't really work however. I'm testing by having a ping/pong host hook call that happens regularly (every 30 seconds) and then use currports app to kill the tcp connection externally.

Anyone have any other ideas. Gonna continue to pound on this problem.

const connectOnce = (function(){
    var connected = false;
    return function(socket, app){
        if (connected) {
            return;
        }
        connected = true;

        appApi = require('./api/app')(socket, app);
        browserWindows = require('./api/browserWindows')(socket, app);
        commandLine = require('./api/commandLine')(socket, app);
        autoUpdater = require('./api/autoUpdater')(socket);
        ipc = require('./api/ipc')(socket);
        menu = require('./api/menu')(socket);
        dialogApi = require('./api/dialog')(socket);
        notification = require('./api/notification')(socket);
        tray = require('./api/tray')(socket);
        webContents = require('./api/webContents')(socket);
        globalShortcut = require('./api/globalShortcut')(socket);
        shellApi = require('./api/shell')(socket);
        screen = require('./api/screen')(socket);
        clipboard = require('./api/clipboard')(socket);
        browserView = require('./api/browserView')(socket);
        powerMonitor = require('./api/powerMonitor')(socket);
        nativeTheme = require('./api/nativeTheme')(socket);
        dock = require('./api/dock')(socket);

        try {
            const hostHookScriptFilePath = path.join(__dirname, 'ElectronHostHook', 'index.js');

            if (isModuleAvailable(hostHookScriptFilePath) && hostHook === undefined) {
                const { HookService } = require(hostHookScriptFilePath);
                hostHook = new HookService(socket, app);
                hostHook.onHostReady();
            }
        } catch (error) {
            console.error(error.message);
        }
    }
})();


function startSocketApiBridge(port) {

    // instead of 'require('socket.io')(port);' we need to use this workaround
    // otherwise the Windows Firewall will be triggered
    server = require('http').createServer();
    io = require('socket.io')();
    io.attach(server);

    server.listen(port, 'localhost');
    server.on('listening', function () {
        console.log('Electron Socket started on port %s at %s', server.address().port, server.address().address);
        // Now that socket connection is established, we can guarantee port will not be open for portscanner
        if (watchable) {
            startAspCoreBackendWithWatch(port);
        } else {
            startAspCoreBackend(port);
        }
    });

    // prototype
    app['mainWindowURL'] = "";
    app['mainWindow'] = null;

    io.on('connection', (socket) => {

        // we need to remove previously cache instances 
        // otherwise it will fire the same event multiple depends how many time
        // live reload watch happen.
        socket.on('disconnect', function (reason) {
            console.log('Got disconnect! Reason: ' + reason);
        });

        global['electronsocket'] = socket;
        global['electronsocket'].setMaxListeners(0);
        console.log('ASP.NET Core Application connected...', 'global.electronsocket', global['electronsocket'].id, new Date());
        connectOnce(socket, app);
    });
}

@danatcofo commented on GitHub (Oct 5, 2020): @MopsieX et all... found a way to externally kill the ports and force a reconnect. http://www.nirsoft.net/utils/cports.html My first pass on a fix is basically to do a connect once method. basically replacing `startSocketApiBridge()` with the following code in main.js. This doesn't really work however. I'm testing by having a ping/pong host hook call that happens regularly (every 30 seconds) and then use currports app to kill the tcp connection externally. Anyone have any other ideas. Gonna continue to pound on this problem. ``` const connectOnce = (function(){ var connected = false; return function(socket, app){ if (connected) { return; } connected = true; appApi = require('./api/app')(socket, app); browserWindows = require('./api/browserWindows')(socket, app); commandLine = require('./api/commandLine')(socket, app); autoUpdater = require('./api/autoUpdater')(socket); ipc = require('./api/ipc')(socket); menu = require('./api/menu')(socket); dialogApi = require('./api/dialog')(socket); notification = require('./api/notification')(socket); tray = require('./api/tray')(socket); webContents = require('./api/webContents')(socket); globalShortcut = require('./api/globalShortcut')(socket); shellApi = require('./api/shell')(socket); screen = require('./api/screen')(socket); clipboard = require('./api/clipboard')(socket); browserView = require('./api/browserView')(socket); powerMonitor = require('./api/powerMonitor')(socket); nativeTheme = require('./api/nativeTheme')(socket); dock = require('./api/dock')(socket); try { const hostHookScriptFilePath = path.join(__dirname, 'ElectronHostHook', 'index.js'); if (isModuleAvailable(hostHookScriptFilePath) && hostHook === undefined) { const { HookService } = require(hostHookScriptFilePath); hostHook = new HookService(socket, app); hostHook.onHostReady(); } } catch (error) { console.error(error.message); } } })(); function startSocketApiBridge(port) { // instead of 'require('socket.io')(port);' we need to use this workaround // otherwise the Windows Firewall will be triggered server = require('http').createServer(); io = require('socket.io')(); io.attach(server); server.listen(port, 'localhost'); server.on('listening', function () { console.log('Electron Socket started on port %s at %s', server.address().port, server.address().address); // Now that socket connection is established, we can guarantee port will not be open for portscanner if (watchable) { startAspCoreBackendWithWatch(port); } else { startAspCoreBackend(port); } }); // prototype app['mainWindowURL'] = ""; app['mainWindow'] = null; io.on('connection', (socket) => { // we need to remove previously cache instances // otherwise it will fire the same event multiple depends how many time // live reload watch happen. socket.on('disconnect', function (reason) { console.log('Got disconnect! Reason: ' + reason); }); global['electronsocket'] = socket; global['electronsocket'].setMaxListeners(0); console.log('ASP.NET Core Application connected...', 'global.electronsocket', global['electronsocket'].id, new Date()); connectOnce(socket, app); }); } ```

claunia commented

2026-01-29 16:42:07 +00:00

@Delpire commented on GitHub (Jan 13, 2021):

@GregorBiswanger is this issue really closed? It was unclear to me based on the last few comments of the merge.

I am seeing an issue where after a period of time, my menu items quit working, and this issue seemed like it may have been the root cause. I could be completely wrong, and if you think so, I can open a new issue. I haven't been able to determine root cause, but it does seem related to a socket disconnect, at least every time I've noticed it, the command prompt has shown a socket disconnect. Losing access to the browser window might explain why the menu items no longer work.

@Delpire commented on GitHub (Jan 13, 2021): @GregorBiswanger is this issue really closed? It was unclear to me based on the last few comments of the merge. I am seeing an issue where after a period of time, my menu items quit working, and this issue seemed like it may have been the root cause. I could be completely wrong, and if you think so, I can open a new issue. I haven't been able to determine root cause, but it does seem related to a socket disconnect, at least every time I've noticed it, the command prompt has shown a socket disconnect. Losing access to the browser window might explain why the menu items no longer work.

claunia commented

2026-01-29 16:42:07 +00:00

@danatcofo commented on GitHub (Jan 14, 2021):

The issue this fixed was basically fixing the eventing link between the back end and front end being broken when the socket got disconnected and then reconnected. So if you attempted to send a message to a specific window, it never made it there because it didn't exist anymore in the browserWindows array.

If your experiencing a disconnect after a while, and you do not see a reconnect, then that is your issue, it's not related to this on first blush. If however you are seeing the reconnect it may be related and would require further investigation and testing.

This change didn't mess with any connect/disconnect base functionality, only with the consumers of those events.

@danatcofo commented on GitHub (Jan 14, 2021): The issue this fixed was basically fixing the eventing link between the back end and front end being broken when the socket got disconnected and then reconnected. So if you attempted to send a message to a specific window, it never made it there because it didn't exist anymore in the browserWindows array. If your experiencing a disconnect after a while, and you do not see a reconnect, then that is your issue, it's not related to this on first blush. If however you are seeing the reconnect it may be related and would require further investigation and testing. This change didn't mess with any connect/disconnect base functionality, only with the consumers of those events.

claunia commented

2026-01-29 16:42:08 +00:00

@Delpire commented on GitHub (Jan 14, 2021):

@danatcofo I am seeing it reconnect. The app continues to work, and the Exit menu item I have works. My other menu items, for which I have written code to do things, stop working. They aren't particularly exciting, they just use explorer.exe to launch a folder or a help file. Those menu items are the only ones that break on the disconnect/reconnect. The only odd thing I may be doing is that I have the callbacks for those menu items tied to a static method on a static class rather than having some sort of instance I create.

@Delpire commented on GitHub (Jan 14, 2021): @danatcofo I am seeing it reconnect. The app continues to work, and the Exit menu item I have works. My other menu items, for which I have written code to do things, stop working. They aren't particularly exciting, they just use explorer.exe to launch a folder or a help file. Those menu items are the only ones that break on the disconnect/reconnect. The only odd thing I may be doing is that I have the callbacks for those menu items tied to a static method on a static class rather than having some sort of instance I create.

claunia commented

2026-01-29 16:42:08 +00:00

@GregorBiswanger commented on GitHub (Jan 14, 2021):

One problem I see is that a .NET library is currently in use for the socket.io support. Unfortunately, it is no longer maintained.

We need an alternative that also supports the latest version of socket.io (3.x) and that we could use without great effort. I'm sure we will get some socket problems improved.

@GregorBiswanger commented on GitHub (Jan 14, 2021): One problem I see is that a .NET library is currently in use for the socket.io support. Unfortunately, it is no longer maintained. We need an alternative that also supports the latest version of socket.io (3.x) and that we could use without great effort. I'm sure we will get some socket problems improved.

claunia commented

2026-01-29 16:42:08 +00:00

@danatcofo commented on GitHub (Jan 15, 2021):

I haven't run into any menu issues myself @Delpire. though I don't use a static method for consumption. I basically do all of my handlers as inline arrow functions where the internals of them do stuff. generally the internals will call instance methods but the actual menu action handler is an arrow function.

Click = async () => {
   // do stuff
}

// or

Click = () => {
   // do stuff
}

@danatcofo commented on GitHub (Jan 15, 2021): I haven't run into any menu issues myself @Delpire. though I don't use a static method for consumption. I basically do all of my handlers as inline arrow functions where the internals of them do stuff. generally the internals will call instance methods but the actual menu action handler is an arrow function. ``` Click = async () => { // do stuff } // or Click = () => { // do stuff } ```

claunia commented

2026-01-29 16:42:08 +00:00

@Delpire commented on GitHub (Jan 16, 2021):

@GregorBiswanger fyi:

@danatcofo - I went ahead and tested this out by removing all my static calls. Now I am just creating the browser window and its menu items in an async method called from Startup.cs' public void Configure(IApplicationBuilder app, IWebHostEnvironment env). Basically I am doing exactly what the example Electron .NET repo is doing.

I tested with several different menu items.

Calling via Click = () => {...}
Calling via Click = async () => {...}
Showing an electron dialog rather than my Process.Start code.

When the app launches, all menu items work correctly no matter how many times I use them. Then the moment I get the follow error, they all stop working and do nothing.

Got disconnect! Reason: transport close
ASP.NET Core Application connected... global.electronsocket RnBU9CurpxHQnecDAAAB 2021-01-16T03:46:05.669Z
HookService is not a constructor
stdout: BridgeConnector connected!

The only menu item that works at that point is my Exit menu item, which does not use the Click property. I also thought maybe it was because my BrowserWindow object was falling out of scope, so I went ahead and added it as a private field to my Startup.cs class. Same issue. Disconnection/Reconnection completely breaks my menu items.

Here is an example of what I am doing:

public async void ElectronBootstrap(string myFolder)
{
    _browserWindow = await Electron.WindowManager.CreateWindowAsync(new BrowserWindowOptions
    {
        Width = 1366,
        Height = 768,
        MinWidth = 515,
        MinHeight = 300,
        Show = false
    });

    MenuItem openFolderMenuItem = new MenuItem
    {
        Label = "Open Folder",
        Click = () =>
        {
            Process.Start("explorer.exe", myFolder).Dispose();
        }
    };

    MenuItem launchDialog = new MenuItem
    {
        Label = "Launch Dialog",
        Click = () =>
        {
            Electron.Dialog.ShowErrorBox("My Dialog Tile", "This is my dialog.");
        }
    };

    MenuItem separator = new MenuItem
    {
        Type = MenuType.separator
    };

    MenuItem exitMenuItem = new MenuItem
    {
        Label = "Exit",
        Role = MenuRole.quit
    };

    MenuItem fileMenu = new MenuItem
    {
        Label = "File",
        Submenu = new MenuItem[] { openFolderMenuItem, launchDialog, separator, exitMenuItem },
        Type = MenuType.submenu
    };

    _browserWindow.SetMenu(new MenuItem[] { fileMenu });
    await _browserWindow.WebContents.Session.ClearCacheAsync();
    _browserWindow.OnReadyToShow += () => _browserWindow.Show();
}

I am using the latest release 9.31.2. I should also mention that I believe I saw that Electron.WindowManager.BrowserWindows was empty after a disconnect and reconnect.

At this point I am thinking my only work around would be using the ElectronHostHook thing to keep all of this code in the main Electron process, which to some extent defeats a lot of the benefits of Electron .NET

@Delpire commented on GitHub (Jan 16, 2021): @GregorBiswanger fyi: @danatcofo - I went ahead and tested this out by removing all my static calls. Now I am just creating the browser window and its menu items in an async method called from Startup.cs' `public void Configure(IApplicationBuilder app, IWebHostEnvironment env)`. Basically I am doing exactly what the example Electron .NET repo is doing. I tested with several different menu items. 1. Calling via `Click = () => {...}` 2. Calling via `Click = async () => {...}` 3. Showing an electron dialog rather than my Process.Start code. When the app launches, all menu items work correctly no matter how many times I use them. Then the moment I get the follow error, they _all_ stop working and do nothing. ``` Got disconnect! Reason: transport close ASP.NET Core Application connected... global.electronsocket RnBU9CurpxHQnecDAAAB 2021-01-16T03:46:05.669Z HookService is not a constructor stdout: BridgeConnector connected! ``` The only menu item that works at that point is my Exit menu item, which does not use the Click property. I also thought maybe it was because my BrowserWindow object was falling out of scope, so I went ahead and added it as a private field to my Startup.cs class. Same issue. Disconnection/Reconnection completely breaks my menu items. Here is an example of what I am doing: ```csharp public async void ElectronBootstrap(string myFolder) { _browserWindow = await Electron.WindowManager.CreateWindowAsync(new BrowserWindowOptions { Width = 1366, Height = 768, MinWidth = 515, MinHeight = 300, Show = false }); MenuItem openFolderMenuItem = new MenuItem { Label = "Open Folder", Click = () => { Process.Start("explorer.exe", myFolder).Dispose(); } }; MenuItem launchDialog = new MenuItem { Label = "Launch Dialog", Click = () => { Electron.Dialog.ShowErrorBox("My Dialog Tile", "This is my dialog."); } }; MenuItem separator = new MenuItem { Type = MenuType.separator }; MenuItem exitMenuItem = new MenuItem { Label = "Exit", Role = MenuRole.quit }; MenuItem fileMenu = new MenuItem { Label = "File", Submenu = new MenuItem[] { openFolderMenuItem, launchDialog, separator, exitMenuItem }, Type = MenuType.submenu }; _browserWindow.SetMenu(new MenuItem[] { fileMenu }); await _browserWindow.WebContents.Session.ClearCacheAsync(); _browserWindow.OnReadyToShow += () => _browserWindow.Show(); } ``` I am using the latest release 9.31.2. I should also mention that I believe I saw that `Electron.WindowManager.BrowserWindows` was empty after a disconnect and reconnect. At this point I am thinking my only work around would be using the ElectronHostHook thing to keep all of this code in the main Electron process, which to some extent defeats a lot of the benefits of Electron .NET

claunia commented

2026-01-29 16:42:09 +00:00

@danatcofo commented on GitHub (Jan 17, 2021):

hmm, well sounds like we have bug still then. I'm assuming you're using windows here rather than macOS as you would be updating the app menu rather than the window menu in that case. Honestly I didn't test your scenario, only tested the socket communication being maintained between the back end and the front end. Looks like there is some more work to do then here. I'll take a look at it soon as I can.

@danatcofo commented on GitHub (Jan 17, 2021): hmm, well sounds like we have bug still then. I'm assuming you're using windows here rather than macOS as you would be updating the app menu rather than the window menu in that case. Honestly I didn't test your scenario, only tested the socket communication being maintained between the back end and the front end. Looks like there is some more work to do then here. I'll take a look at it soon as I can.

claunia commented

2026-01-29 16:42:09 +00:00

@Delpire commented on GitHub (Jan 19, 2021):

@danatcofo yes I am using Windows.

I can confirm that the issue is still there in master as well. I pulled down the master branch and added a menu item to ElectronNET.WebApp and built it. Once it disconnects and reconnects the menu item is broken. This branch includes your updates to the Typescript files from this PR
https://github.com/ElectronNET/Electron.NET/pull/486

@Delpire commented on GitHub (Jan 19, 2021): @danatcofo yes I am using Windows. I can confirm that the issue is still there in master as well. I pulled down the master branch and added a menu item to ElectronNET.WebApp and built it. Once it disconnects and reconnects the menu item is broken. This branch includes your updates to the Typescript files from this PR https://github.com/ElectronNET/Electron.NET/pull/486

claunia commented

2026-01-29 16:42:09 +00:00

@Delpire commented on GitHub (Jan 20, 2021):

I have some new interesting information. It seems the reason for the disconnect matters and that different machines act differently. I have tested this on 3-4 different machines. On the first machine I saw the issue, it was a physical machine, and it took a while for the problem to occur. On my VM, it happens very frequently. It will basically always happen within 15 minutes or so of launching the application.

On a different physical machine, I left the application running and never saw the disconnect even after 5 or 6 hours. I did however notice a different disconnect:

stdout: Screen Locked detected from C#
stdout: The system is going to sleep
Got disconnect! Reason: ping timeout
ASP.NET Core Application connected... global.electronsocket SAzBWIRhtFHAJudoAAAA 2021-01-19T21:16:52.184Z
stdout: BridgeConnector connected!
stdout: Screen unlocked detected from C#
stdout: Screen Locked detected from C#
stdout: The system is going to sleep
stdout: The system is resuming
Got disconnect! Reason: ping timeout
ASP.NET Core Application connected... global.electronsocket SAzBWIRhtFHAJudoAAAA 2021-01-20T00:28:17.434Z
stdout: BridgeConnector connected!
stdout: Screen unlocked detected from C#

Even after that, my menu item still works correctly. So it seems that getting Got disconnect! Reason: ping timeout is fine, but getting Got disconnect! Reason: transport close breaks things.

@Delpire commented on GitHub (Jan 20, 2021): I have some new interesting information. It seems the reason for the disconnect matters and that different machines act differently. I have tested this on 3-4 different machines. On the first machine I saw the issue, it was a physical machine, and it took a while for the problem to occur. On my VM, it happens very frequently. It will basically always happen within 15 minutes or so of launching the application. On a different physical machine, I left the application running and **never** saw the disconnect even after 5 or 6 hours. I did however notice a different disconnect: ``` stdout: Screen Locked detected from C# stdout: The system is going to sleep Got disconnect! Reason: ping timeout ASP.NET Core Application connected... global.electronsocket SAzBWIRhtFHAJudoAAAA 2021-01-19T21:16:52.184Z stdout: BridgeConnector connected! stdout: Screen unlocked detected from C# stdout: Screen Locked detected from C# stdout: The system is going to sleep stdout: The system is resuming Got disconnect! Reason: ping timeout ASP.NET Core Application connected... global.electronsocket SAzBWIRhtFHAJudoAAAA 2021-01-20T00:28:17.434Z stdout: BridgeConnector connected! stdout: Screen unlocked detected from C# ``` Even after that, my menu item **still works correctly**. So it seems that getting `Got disconnect! Reason: ping timeout` is fine, but getting `Got disconnect! Reason: transport close` breaks things.

claunia commented

2026-01-29 16:42:09 +00:00

@Delpire commented on GitHub (Jan 26, 2021):

I just thought I would mention that my work around is to take advantage of the ElectronHostHook and Electron's IPC. I can put all my code to create my menu items in some Typescript in an ElectronHostHook, and then if I need a file path that I get at runtime I can pass the file path via electron's IPC. I could use the HookService, but I am worried about the reliability of the socket dependency. So I am going from the ASP .NET Core code to the ipcRenderer via JSInterop, and then the ipcRender tells the ipcMain to keep track of a global variable with the folder path that the menu item's click method uses. Until I feel confident in the communication between the ASP .NET Core process and the main electron process, this route, while more indirect, seems robust.

So far I have not seen any problems with this approach. When the socket inevitably disconnects and reconnects all my menus are still working correctly.

@danatcofo @GregorBiswanger - Can you guys think of any gotcha's or issues with this approach?

@Delpire commented on GitHub (Jan 26, 2021): I just thought I would mention that my work around is to take advantage of the ElectronHostHook and Electron's IPC. I can put all my code to create my menu items in some Typescript in an ElectronHostHook, and then if I need a file path that I get at runtime I can pass the file path via electron's IPC. I could use the HookService, but I am worried about the reliability of the socket dependency. So I am going from the ASP .NET Core code to the ipcRenderer via JSInterop, and then the ipcRender tells the ipcMain to keep track of a global variable with the folder path that the menu item's click method uses. Until I feel confident in the communication between the ASP .NET Core process and the main electron process, this route, while more indirect, seems robust. So far I have not seen any problems with this approach. When the socket inevitably disconnects and reconnects all my menus are still working correctly. @danatcofo @GregorBiswanger - Can you guys think of any gotcha's or issues with this approach?

claunia commented

2026-01-29 16:42:10 +00:00

@danatcofo commented on GitHub (Jan 28, 2021):

@Delpire I went ahead and opened up a fresh ticket #553 for the menu item issue... Go ahead and comment any extra information your might have there and if I got anything wrong, on the ticket as well.

One think I'm interested in is if this also happens for other menuitems such as the tray, app or dock menu's (now that we have dock menus) especially as mac generally doesn't support browser window menues. However I don't know of an app like CurrPorts on windows that allows me to forcibly close a port in Mac like that does.

@danatcofo commented on GitHub (Jan 28, 2021): @Delpire I went ahead and opened up a fresh ticket #553 for the menu item issue... Go ahead and comment any extra information your might have there and if I got anything wrong, on the ticket as well. One think I'm interested in is if this also happens for other menuitems such as the tray, app or dock menu's (now that we have dock menus) especially as mac generally doesn't support browser window menues. However I don't know of an app like CurrPorts on windows that allows me to forcibly close a port in Mac like that does.

claunia commented

2026-01-29 16:42:10 +00:00

@Delpire commented on GitHub (Jan 28, 2021):

@danatcofo thank you! I have added some more information. I will watch that issue moving forward.

@Delpire commented on GitHub (Jan 28, 2021): @danatcofo thank you! I have added some more information. I will watch that issue moving forward.

claunia referenced this issue

2026-01-29 16:58:23 +00:00

[PR #528] [MERGED] Issue/527 #1203

claunia referenced this issue

2026-01-29 16:58:24 +00:00

[PR #528] Issue/527 #1206

Sign in to join this conversation.