NWJS Chrome App ID Changes Every Time You Start The App If The App Is Zipped - Breaks chrome.storage.local #5970
Description
I'm running v0.23.2 on Windows 10 (64 bit) but I have observed the issue in older versions, so I don't think it is a recent regression or anything.
I have a chrome app that I'm working on deploying via NWjs since Google is killing the platform. I've noticed that the property chrome.runtime.id will stay the same if you open and close the app, reboot, whatever so long as you are running your application directly from a folder.
such as: nw.exe c:\path\to\app\folder
If you take your application folder and zip it (whether you rename the zip extension with .nw or not) and run it that way, or if you combine the nw executable with your zipped application package and run it that way, chrome.runtime.id will be different every single time you run the application.
such as: nw.exe c:\path\to\app.zip or nw.exe c:\path\to\app.nw
This might not seem like a big deal until you realize that the app ID changing breaks the chrome.storage.local API. I've verified that when running against a zipped app, local storage is written to and read from just fine until you close the app and start it again. Now it generates a new ID and therefore it looks in a different folder for local storage and doesn't see the previously saved data. This also has a consequence of eating up more and more disk space each and every time you run the application, because it generates a new folder with local settings and data every single time you run the app.
If you run even a basic barebone sample chrome app that uses a background.js file to pop open a window you will be able to easily reproduce and observe this by checking out chrome.runtime.id from the javascript console, so I know this isn't something exotic about my entire app. I'm guessing it's a bug in NWJS, but I am not sure if I am just missing something obvious.