NWJS not completely closing when exiting app

Bugs will be moved here once resolved.

Post » Wed Feb 24, 2016 5:47 pm

So I have fiddled around with this one too now.

My findings so far:

My main development machine is Win 8.1 Home patched to date, R221, NWjs 0.13.0 beta6
My notebook runs on a Win 7 Pro 64 Bit patched to date, neither C2 nor NW.js installed, I just run compiled NW apps.

Previewing in NW.js works exactly once per project name change.

Why does it work: A new AppData\Local\%username%\%ProjectName% folder structure is created upon execution.
This is of course a tedious workaround as it inflates the appdata folder.

Running the nw.js instances in this way I noticed that they appear as 32bit instances.

Exporting to a built application is the same, HOWEVER, the 64 bit will fire up every time and "just" leave those unpleasant zombie processes behind - which the 32 bit version also does.

The catch:

After having a look in AppData\Local\%username%\%ProjectName%\User Data\ , you will notice some garbage text files there. I call them garbage files because as of now I'm to ignorant to oversee the implications when they're not there ;)

First Run 0 KB - created when the app is run for the first time
lockfile 0 KB - existent while the app is running
Local State 2 KB, some config and statistic tracking going on there

Deleting the First Run won't do anything, deleting the lockfile is prohibited by the running app, but
after removal of the local state - tadaaaa, your NW app will fire up again! Until the next startup... because a new local state will be generated. Same is true if you mess up the Local State (bad syntax etc.). It will dump the old file to Local State.bad and create a fresh one.

That brings me to the conclusion that renaming the project is equivalent to deletion of the Local State file.
Didn't bother to compare the folder structures changes yet, but comparing the to Local State files (after 32 Bit run and 64 Bit run) reveals some differences in the files.

The first is the missing parameter "browser":{"last_redirect_origin":""} in the 32 Bit version.
Second being in the structure info_cache, the "is_using_default_name":false is set to true in the 32 Bit version.
The last noticable difference is the absence of "plugin_stats2":[] in the 32 Bit version.

However, bad news is that filling up the missing, different parameters in the 32 Bit version will not get it to run.

This all is a bit separated from the zombie processes issue, as I can confirm that building an empty project will always close properly (32 or 64 bit).
Image
B
16
S
4
G
1
Posts: 120
Reputation: 1,801

Post » Mon Feb 29, 2016 9:00 pm

@madspy CloseAppTestNw13B5 seems to kill the ghost for me - however, my own app ghosts
B
36
S
8
G
5
Posts: 436
Reputation: 5,967

Post » Mon Feb 29, 2016 10:27 pm

thanks for the reply @czar
Image Image
B
19
S
10
G
116
Posts: 865
Reputation: 60,433

Post » Fri Mar 04, 2016 6:06 am

Has anyone tested this issue with the new NW.JS builds released today?
FREEDOM: Diegesis - Out Now for Windows! http://freedom.quicksandgames.com
B
21
S
5
G
1
Posts: 83
Reputation: 1,793

Post » Sat Mar 05, 2016 7:42 pm

I tested it with the rc1 3/3 release of nw.js and it still happens for me. I've also heard tale of renaming the project solving the problem, and that doesn't work either.

I export to nw.js to get the executables, and when I run either the Windows 32 or 64 bit versions of nw.exe it happens. I just run the executables directly. I do not close through any internal close function, but close with the X on the window. Having looked around, I've heard a lot of complaining about the issue outside of Construct itself, and I'm reasonably confidant it's an nw.js issue. It appears to create a parent and two children (though I could be mistaken) and when closed it removes the two children, but not the parent. If you run it again it creates three new processes, two of which close when exiting the program, leaving two nw.exe in the process tab. This seems to continue indefinitely. I've put my game up for download and I've seen comments on almost every site related to the game complaining about the issue, so it appears to be a problem with the game files and not just my computer.

It's a bit bloated for an example of the problem, but you can find my game, which does it, here:
http://gamejolt.com/games/tofu-tower/125361
B
3
Posts: 1
Reputation: 177

Post » Sun Mar 06, 2016 11:35 pm

Closing the game seems to work properly (and not leave behind background processes) with having the Browser object execute the Javascript code "var gui = require('nw.gui'); gui.App.quit();". Can anyone else confirm that?

If so maybe there is a way to work that in so that NW.JS will automatically execute that code on the window close event.
FREEDOM: Diegesis - Out Now for Windows! http://freedom.quicksandgames.com
B
21
S
5
G
1
Posts: 83
Reputation: 1,793

Post » Sun Mar 06, 2016 11:38 pm

@Quicksand see my post page 8
Image Image
B
19
S
10
G
116
Posts: 865
Reputation: 60,433

Post » Mon Mar 07, 2016 12:22 am

Ok so if I understand correctly you've modified the NW plugin to have a "close app" action. But to me there should be a way for the basic behind-the-scenes runtime scripts to automatically incorporate that action when the window's X is clicked.

I don't really know Javascript at all but I think it should be something sorta like this:

var win = nw.Window.get();

"var gui = require('nw.gui');

nw.Window.get().on('close', function() {
gui.App.quit();
}
FREEDOM: Diegesis - Out Now for Windows! http://freedom.quicksandgames.com
B
21
S
5
G
1
Posts: 83
Reputation: 1,793

Post » Mon Mar 07, 2016 12:37 am

doable... but I prefer hide windows frame in order to avoid user to close the app by clicking on window's X
Image Image
B
19
S
10
G
116
Posts: 865
Reputation: 60,433

Post » Mon Mar 07, 2016 12:49 am

MadSpy wrote:doable... but I prefer hide windows frame in order to avoid user to close the app by clicking on window's X


That's the solution I'm using for my game for now. And I've managed to get it so that you can drag the window by its border while still being able to click within the window normally, without dragging it. Now the only worry is if someone right clicks on the game in the taskbar and closes it that way (I have a message telling the player not to, but that's not ideal).
FREEDOM: Diegesis - Out Now for Windows! http://freedom.quicksandgames.com
B
21
S
5
G
1
Posts: 83
Reputation: 1,793

PreviousNext

Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 2 guests