Nw.js: nw.Window.open callback returns undefined object when using new_instance

[tolrtd]

In nwjs 0.13-beta6, win64 SDK build, when opening a new window with "new_instance" set to true, the Window.open callback returns an undefined object. Even the 'this' object is undefined.

nw.Window.open('new.html', {
   'new_instance': true
},function(win){
   // win is undefined here
});

Edit: Unless this is by design because the new window will have a new context that we are not supposed to access?

[rogerwang]

This is currently a limitation, will fix it. Before that you can call nw.Window.get() in the new window ...

[tolrtd]

I'm trying to get the handle of the new_instance child window from the parent window so that I can close it from the parent. What would you suggest as the proper way to do this right now, since the nw.* contexts are not shared?

[tolrtd]

To add to this - it seems that when I use new_instance = true on any nw.Window.open, all future windows that open have this issue with the callback object being undefined, even if I explicitly set new_instance = false.

[MehmetKursat]

+1 for this issue to be fixed.

[tolrtd]

Roger, any idea when this will be fixed?

[rogerwang]

I'll see if it can catch the 0.13.0 release.

[Gimmeaphatbeat]

+1. loaded event also not firing

[vankasteelj]

Still happening in 0.13.2

[kit92]

also despite a variety of implementations, in v14.1 sdk, calling nw.Window.get() only gets the first window that was created, not the focused window.

[kailniris]

after creating new window with
nw.Window.open('new.html', {
'new_instance': true
},function(win){
// win is undefined here
});

in the new window nw object will be undefined (e.g: in thew new window console)

version 1.4.5

[alexsmith540]

I fought this same issue most of today as well and finally got it to work (v0.15, windows 10 box).
If you're opening an external URL like I am in a new_instance, i.e. nw.Window.open('https://bar.foo.com',... you need to do a couple of things to make nw.Window.open callback return your Window.

• inside your package.json manifest, set "node-remote":"https://*.foo.com" (you can pass in an array of string patterns too)
• If the content displayed uses requirejs or any other require that might get clobbered by mixed context mode, you absolutely MUST NOT run your app with --mixed-context

For some wild reason that all made my new_instance window.open callbacks start returning the Window and not undefined.

voodoomagic

[kailniris]

@rogerwang
I tried out new_instance again in 1.7.0 version, the nw.Window.open callback still return undefined but in the new window the nw object is no longer undefined.
Its pretty handy, the new window is on another thread i guess cuz eg. window.print() does not freeze the main window. The only thing is needed is access the new window context, can it even be achieved somehow considering the thing the other window is on other thread?

[edi9999]

Same issue for me, it would be great to fix this :-)

[edi9999]

From what I can see, it seems that this doesn't work since the 0.13 migration (eg I tried on 0.14.7 and it doesn't seem to work either).

[freeneutron]

Same issue in v0.18.0 for Linux (ia32)

[gpetrov]

still a bug in 0.18.5 ... hope it will be fixed soon, we really need it

[vankasteelj]

We can handle some things with the chrome api, but we don't have access to DOM or anything truly usefull :/

[gpetrov]

well having a new window as nwjs instance gives us a lot of freedom to separate heavy duty tasks that normally block the UI, while still having the full power of web and node together.

Also this gives us a great level of isolation - if the separate process window crashes, the main window can detect this and take appropriate action, so not the whole app is crashing.

only if we could have the handle returned from the new window, so we can keep control of it.

@rogerwang please make sure the fix is in the next build, as I saw it was already fixed in the chromium upstream?

This will allow us to build great speedy apps with nwjs with great reliability!

[gpetrov]

@rogerwang - were you able to address this issue in 0.18.7?

We really need urgently the handle to the new window running in separate process so we can communicate with it more reliable.

[rogerwang]

@gpetrov unfortunately this is not to be fixed in 0.18 as it require more important changes than expected.

To work around it before that and offload heavy duty tasks, you may consider using Node in Web workers: http://nwjs.io/blog/v0.18.4/

[gpetrov]

That is a sad news - will it be in the 0.19?

We tried the WebWorkers but unfortunately they don't work for us first then don't support WebRTC yet - and second and some of the modules we use, use process.binding('...') and that gave us errors in webWorkers

[alexsmith540]

I have a workaround but not sure if you're going to like it...
So I have a multi screen app and each screen needs its own renderer process hence the need for new_instance. You can use inject_js_start to inject websocket client code/libs into the windows. If you set an id when spawning the window it's present inside nw.Window.get().appWindow.id (or something like that sorry at an airport on mobile, ha). I then send that ID back to the nodejs socket server and boom: communication. HackyAF but we absolutely needed features from 0.18 and couldn't stay on 0.12 anymore...

[rogerwang]

@gpetrov I'm afraid I can't promise a deadline but I'll work on this issue at the highest priority.

[kailniris]

I don't really understand this.
new_instance means new render process which means new thread, new memory heap. JavaScript is designed to be single threaded , you can't access other threads memory heap so you can't just access other new_instance windows variable that easily.
Am I missing something important here?

[gpetrov]

thanks @rogerwang ! really appreciate it.

Unfortunately we hit another road block in webRTC ... seems even if loaded in separate process, due to some chromium bugs in RTCPeerConnection.close it hangs not only the child process web rendered but also the main web renderer! And we thought those will be totally separated when ran with new_instance
See also https://github.com/feross/webtorrent/issues/903

@alexsmith540 we got the communication working with https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API which works great. It is only that we can't kill the client process if it gets stuck.

[rogerwang]

Please submit an issue for webrtc bug. Thanks.

On Wed, Nov 16, 2016, 8:46 PM George Petrov [email protected]
wrote:

thanks @rogerwang https://github.com/rogerwang ! really appreciate it.

Unfortunately we hit another road block in webRTC ... seems even if loaded
in separate process, due to some chromium bugs in RTCPeerConnection.close
it hangs not only the child process web rendered but also the main web
renderer! And we thought those will be totally separated when ran with
new_instance
See also feross/webtorrent#903
https://github.com/feross/webtorrent/issues/903

@alexsmith540 https://github.com/alexsmith540 we got the communication
working with
https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API
which works great. It is only that we can't kill the client process if it
gets stuck.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nwjs/nw.js/issues/4418#issuecomment-260937721, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKGGbziG5SRfEU66V_volOJatU-sKxTks5q-vslgaJpZM4HdLn9
.

[rogerwang]

And please submit issues you found in Node + Web worker.

On Wed, Nov 16, 2016, 8:48 PM Roger [email protected] wrote:

Please submit an issue for webrtc bug. Thanks.

On Wed, Nov 16, 2016, 8:46 PM George Petrov [email protected]
wrote:

thanks @rogerwang https://github.com/rogerwang ! really appreciate it.

Unfortunately we hit another road block in webRTC ... seems even if loaded
in separate process, due to some chromium bugs in RTCPeerConnection.close
it hangs not only the child process web rendered but also the main web
renderer! And we thought those will be totally separated when ran with
new_instance
See also feross/webtorrent#903
https://github.com/feross/webtorrent/issues/903

@alexsmith540 https://github.com/alexsmith540 we got the communication
working with
https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API
which works great. It is only that we can't kill the client process if it
gets stuck.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nwjs/nw.js/issues/4418#issuecomment-260937721, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKGGbziG5SRfEU66V_volOJatU-sKxTks5q-vslgaJpZM4HdLn9
.

[rogerwang]

reassign to @ghostoy since we found another way to support this.

[semmel]

This issue is still a major roadblock for us 🚧 🚧

We cannot load _remote_ pages in popup Windows using nw.Window.open unless we grant them _full local Node rights_ (ie. make them Node Frames by including their urls in the node-remotemanifest entry).

Because unless they are Node Frames the nwWindow argument in the callback to nw.Window.open will be undefined.

But that's a major security concern: Granting full _local execution rights_ to _remote source code_.
Since we don't want to do that we have to remain on nwjs 0.16.1 😢

[rogerwang]

@semmel before we fix it please see the workaound in the comment earlier: https://github.com/nwjs/nw.js/issues/4418#issuecomment-260931505
Another is wrap the remote page in the new window in a webview and write your code outside the webview.
The communication between windows in different processes can be done via BroadcastChannel

[rogerwang]

btw, if you use webview in the new window to load external page, new_instance is not needed at all, because pages in webview are guaranteed to be loaded in a new renderer process.

[semmel]

@rogerwang Thank you very much for the comments!
I was able to discover yet another workaround:
In package.json when I set "main": "local.html", then the callback in

// local.html
nw.Window.open("http://remote/page.html", {}, function callback(nwWindow){
   assert(nwWindow !== undefined) // works fine
});

gets delivered the right nwWindow object, also with remote/page not being a Node Frame. (no bug) ✅

However when in package.json I set "main": "app.js", , and then

// app.js
//.. some preparations
nw.Window.open("local.html", {}, function callback(nwWindow){
   assert(nwWindow !== undefined) // works fine
});

but now

// local.html
nw.Window.open("http://remote/page.html", {}, function callback(nwWindow){
   assert(nwWindow !== undefined) // FAILS!
});

🐛
So I refactored my app to launch the main html page local.htmldirectly from the manifest file on start-up. So far it looks good. :crossed_fingers:

[mscreenie]

Still an issue in 21? Kindly see if this can be fixed.

also
editor = nw.Window.open()

editor is undefined.

[Christywl]

Reproduce on Linux/Windows with nwjs-sdk-v0.21.6. When opening a new window with "new_instance" set to true, the Window.open callback returns an undefined object

[vankasteelj]

isn't that normal? "new instance" litteraly means opening a brand new instance, hence separate from the main thread. What's worrying is that the callback is undefined if the file or remote url isnt working, for example try to open www.nonsense-gngngngn.com in a new window

[mscreenie]

Any update on the callback?

[gomestai]

so are there any other way to pass variable?

[anesuc]

I am working on an OS based on node, i.e using nw js for Apps. Right now I have it running Apps as child processes due to this very bug. And as a result things like the browser (which uses webview) freezes the whole thing at times because they are running off the same process. Essentially I have to halt third party Apps from being used until this problem is resolved.

[kailniris]

@anesuc Why don't you open third party apps in new instances?

[anesuc]

@kailniris The main system instance needs full access to the Apps so that I can control them which also include things such as theming etc

[Rhodolite]

This is an issue for me still.

In particular with the following:

 nw.Window.get().showDevTools(
                null,
                function(dev_win){
                    console.log('dev_win:', dev_win);
                    console.log('arguments:', arguments.length);
                }
            );

This will log an undefined with 0 arguments (it will also, properly open up the Developer Tools window)

From the documentation at http://docs.nwjs.io/en/latest/References/Window/#winshowdevtoolsiframe-callback

"callback(dev_win) {Function} callback with the native window of the DevTools window."

I'm reporting this under this bug since as far as I can tell the two are related & the same issue

[f3l1x]

@rogerwang Hi, is there any progress here? Can I help you with something?

It would be nice to have some working workaround. :-) Will Broadcast/Channel API work?

[rogerwang]

Hi Broadcast Channel would totally work. Using it to bridge the JS part of NW API implementation in different windows is the plan. ghostoy was working on it but he left the team later and the work has been stalled. Feel free to pick it up if you like

[f3l1x]

Thanks @rogerwang for the quick answer. Is there any way how to pass any args or something to the new instance?

nw.Window.open('https://github.com', {new_instance: true, args: {foo: bar}});

---

I was wondering, can I use frameId for access the window? Or it's absolutely impossible to attach the new instance's window object.

[lilliesAndRoses]

It looks like the new window does get created.
But the challenge is getting its handle. APIs like chrome.app.window.getAll also seem to be failing.
Is there any way to get that handle?
How can two windows created in separate renderer process communicate?

[rogerwang]

At least BroadcastChannel API can be used to communicate between windows.

On Fri, May 18, 2018, 7:50 PM lilliesAndRoses [e-mail]
wrote:

It looks like the new window does get created.
But the challenge is getting its handle. APIs like
chrome.app.window.getAll also seem to be failing.
Is there any way to get that handle?
How can two windows created in separate renderer process communicate?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nwjs/nw.js/issues/4418#issuecomment-390183035, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKGGWvFkQcw-8okU2NOYQLJT5dEROhrks5tzrWLgaJpZM4HdLn9
.

[rogerwang]

This would be fixed after #5875, which has some progress recently.

[anesuc]

This is a great development! Thanks for the update!

[tolrtd]

Will this fix #6724 as well? That one is fairly urgent for me.

[Adrriver]

Almost two years later, this defect is still without resolution??

[rogerwang]

The depending issue #5875 is under active development and will be released soon. We'll need testers for that issue. Once it's resolved this one will be fixed easily. Thanks.

[rogerwang]

0.35.4 was just released with a testing version of #5875. This issue is fixed under it. Please see more information in that issue. Thanks.

[tolrtd]

Thank you Roger for this project. You are enabling many people to create the future!

[eiro10]

Still happening in 0.40.1-sdk-x64