UI broken with nw.js 0.42.6

I tried running Purr Data with the latest version of nw.js (0.42.6). There is a problem that seems to prevent window elements from being created. For example, the preferences dialog and patch windows are simply blank:

Purr Data with nw.js version 0.42.3 doesn't have this issue.

I don't see any useful errors logged in the console.

Try this:

1. Right click on the main Pd window and choose "Inspect Background Page"
2. Right click on one of the broken patch windows and choose "Inspect"
3. Right click on one of the broken patch windows and choose "Inspect Background Page"

For each devTools window that pops up, click the tab labelled "Console".

Do you see any red errors in any of them?

There isn't a right click menu for any of the windows. Unless I select some text, in which a menu appears that just says 'copy'. If I run the nw binary from the nw.js tarball, I get the same thing - no right click menu unless I select some text.

I noticed that Purr Data by default uses nw.js v0.24.4 (that's what the top level Makefile fetches), and the menu does appear in that version.

So, perhaps in the short term, I need to start using the older nw.js version that you are testing with, and in the longer term we should figure out this issue and move Purr Data to use latest nw.js by default.

There isn't a right click menu for any of the windows.

What if you try clicking on the Pd window before you try opening the Preferences dialog and testtone patch?

and in the longer term we should figure out this issue and move Purr Data to use latest nw.js by default.

The bigger blocker is getting the latest nw.js to compile on arm. Without that we start crossing Ecmascript version boundaries and all kinds of other problems that eat up too much time.

What if you try clicking on the Pd window before you try opening the Preferences dialog and testtone patch?

The same. I think something has changed in nw.js itself, since I see the same behaviour with running the nw binary directly -- there's a right-click menu with 0.24.4, and no right-click menu with 0.42.*

The bigger blocker is getting the latest nw.js to compile on arm. Without that we start crossing Ecmascript version boundaries and all kinds of other problems that eat up too much time.

I see! I didn't realize that. I had a read of https://github.com/LeonardLaszlo/nw.js-armv7-binaries/issues, which was enlightening.

The same

Open the "Help" menu and choose "Show devTools"

Rank speculation-- you downloaded the "NORMAL" version of nw.js and not the "SDK" version.

Rank speculation-- you downloaded the "NORMAL" version of nw.js and not the "SDK" version.

Completely correct. Thanks for your patience :)

I now see the 'inspect' menu options. I inspected various things and generally saw no errors, but this one popped up eventually on opening the 'Show DevTools' window (which also shows up as blank):

VM195:1 Uncaught ReferenceError: register_window_id is not defined
    at <anonymous>:1:1
    at NWWindow.eval (extensions::nw.Window:368)
    at NWWindow.<anonymous> (index.js:443)
    at NWWindow.<anonymous> (extensions::nw.Window:196)

Maybe it's worth noting that the page content of the 'preferences' page is all present, when I look in the inspector, but it's hidden due to a display: none style attribute.

I noticed something about "NW2 mode" in the nw.js 0.43 release notes: https://nwjs.io/blog/nw2-mode/

It's quite a coincidence that NW2 mode was enabled by default between 0.42.3 and 0.42.6, and that's also when this issue appeared.

I tried adding the --disable-features=nw2 flag to pd's invocation of nw. That triggered a different issue where the GUI loads and then exits immediately leaving only this error on the console:

[2415:2415:1211/120615.765847:ERROR:extension_function_dispatcher.cc(594)] Permission denied for nw.App.quit

The same seems to happen with 0.43.0 and 0.42.6.

So you still have blank windows for testtone and preferences?

With nw.js 0.43.0 and 0.42.6, yes.

register_window_id is called from nw_create_window in index.js.

When in doubt I assume that the breakage occurs in the least used API. In this case that would be nw.js' Window methods. So the first thing to check is the eval method of nwjs Window object in line 443 of index.js. Did something change in recent versions of nw.js? Is it buggy and somehow doesn't evaluate in the correct context?

You can also try adding a line to print the eval_string and then manually feeding the arguments in to a direct call of register_window_id in the devTools console for the dialog or patch window. (E.g., right-click and choose "Open Page.") If that works, try getting a reference to the nwjs Window for the dialog and calling the eval method manually with that same eval_string.

Here's another one to check-- notice that the "loaded" event is for the nwjs Window object, not the DOM window. nwjs documentation claims that it behaves the same but does not depend on the DOM. So I'd check the veracity of that, too-- for example you can change it to register that callback for the DOM "onload" member, or add a listener for the "load" event. If it works in that case then nw.js failed to keep their "loaded" event stable through the recent versions.

I did a little further investigation.

Switching the callback in new_create_window() to use new_win.window.onload = ... rather than new_win.on("load") doesn't fix the issue.

I added some traces near index.js line 443, where new_win.eval() is called. This is the code I added:

                  new_win.eval(null, "console.log(document.location.pathname);");
                  new_win.eval(null, "console.log(document.body.getElementsByTagName('script')[0]);");

And here is the output in the console of the index.html window:

VM174:1 /index.html
VM175:1 <script src=​"./​console_search.js">​</script>​
index.js:449 eval this: register_window_id("prefs", null);
VM176:1 Uncaught ReferenceError: register_window_id is not defined
...

So, it seems that register_window_id is undefined here because the code is executing in the context of ìndex.html rather than pd_canvas.html. I don't understand why, though -- pdgui != new_win here, and inspecting the new window shows pd_canvas.html. Perhaps this is indeed a strange regression in nw.js.

I guess the next step would be to produce a minimal testcase for nw.js where one window creates another and evaluates code in the context of the new window, to see if the same issue occurs.