Possible issue with opening a window from a second window using nw.gui on 0-9-0-rc2 and 0.8.4

5 views
Skip to first unread message

james.m...@a-cti.com

unread,
Feb 5, 2014, 1:11:46 PM2/5/14
to node-...@googlegroups.com
I'm on nw-0.9.0-rc2 and 0.8.4, and I noticed that when I try to open a window from another opened window, the new window ends up being a copy of the 2nd window.

Here's an example:

index.html - Opened by default from the manifest

gui.Window.open('common/nw-desktop-notifications/nw-desktop-notifications.html', {
frame: false,
toolbar: false,
width: 290,
height: 100,
'always-on-top': true,
show: true,
resizable: false
});

// the above window opens just fine.

contacts.html
Now, I have another window that I open from index.html, and if I run the same code from contacts.html, a duplicate copy of contacts.html opens up:

gui.Window.open('common/nw-desktop-notifications/nw-desktop-notifications.html', {
frame: false,
toolbar: false,
width: 290,
height: 100,
'always-on-top': true,
show: true,
resizable: false
});

// when run from contacts.html, a duplicate copy of contacts.html opens up.


I tried using window.open instead of gui.window.open, and the correct page opens, but I need the power of nw.gui in order to remove the toolbars and frame from the window.  Am I doing something wrong or is this a bug?


Thank you,
James 

james.m...@a-cti.com

unread,
Feb 5, 2014, 1:43:22 PM2/5/14
to node-...@googlegroups.com, james.m...@a-cti.com
Additional details:  After turning on the toolbar and frame, I see the following in the address bar:

file:///Users/jem/Documents/SynclioLocalApp/synclio-chrome-app/designC/contacts.html#/contacts

I also uncovered this issue https://github.com/rogerwang/node-webkit/issues/1365 where a user has a similar issue and is told to come here.  Why the different behavior?  The window I'm trying to open can clearly be reached relative to the currently open window with window.open.  Are we sure this isn't a bug?

Also, not sure if this is related but from my index.html page, the one opened from the package.json, window.root contains the path on the file system to my application, but in contacts.html it's an object.  Again, not sure if that's related but it's just an observation.

Thanks again,
James

james.m...@a-cti.com

unread,
Feb 5, 2014, 1:57:35 PM2/5/14
to node-...@googlegroups.com, james.m...@a-cti.com
If I run the same code from the index page, the path is of course correct in the address bar:

file:///Users/jem/Documents/SynclioLocalApp/synclio-chrome-app/common/nw-desktop-notifications/nw-desktop-notifications.html

Hope this helps, and let me know if I should file this as a bug.

James

Laszlo Z. Antal

unread,
Feb 5, 2014, 2:18:23 PM2/5/14
to node-...@googlegroups.com, node-...@googlegroups.com, james.m...@a-cti.com
Hi,

On Feb 5, 2014, at 10:57 AM, james.m...@a-cti.com wrote:

If I run the same code from the index page, the path is of course correct in the address bar:

file:///Users/jem/Documents/SynclioLocalApp/synclio-chrome-app/common/nw-desktop-notifications/nw-desktop-notifications.html

Hope this helps, and let me know if I should file this as a bug.

James

I can't reproduce it with 0.8.4 but I'm not using a bundle app. Is your app bundled? Have you tried using app:// to avoid guessing of the relative path?

Laszlo

--
You received this message because you are subscribed to the Google Groups "node-webkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-webkit...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

james.m...@a-cti.com

unread,
Feb 5, 2014, 4:08:25 PM2/5/14
to node-...@googlegroups.com, james.m...@a-cti.com
I'm running from the command line since this is in development, so no, it's not bundled, but it will be for release.  app:// doesn't appear to have any luck locating the files.  The dev tools just show an empty body and empty head.

Still seems like a bug regardless of whether or not it works when packaged.  If a developer can't quickly and efficiently test changes in development, that sort of defeats the purpose of having a development mode.

At any rate, I worked around this as follows, for anyone else who is interested:

    if(window.opener != null) {
var win = window.opener.gui.Window.open('../designB/SynclioLocalUI/menu.html', { frame: true, toolbar: true, width: 590, height: 500, 'always-on-top': true, show: true, resizable: true 
});    
        } else {
var win = gui.Window.open('../designB/SynclioLocalUI/menu.html', { frame: true, toolbar: true, width: 590, height: 500, 'always-on-top': true, show: true, resizable: true });

       }

If anyone's windows go any deeper than one level, just override gui.Window.open with a method that delegates to window.opener until window.opener is null, then call the gui.Window.open from the nw.gui module.

In other words, just use the nw.gui module from the main, originally opened window.  It's a hack, but it works.  

Thank you for your help,

James

james.m...@a-cti.com

unread,
Feb 5, 2014, 4:25:16 PM2/5/14
to node-...@googlegroups.com, james.m...@a-cti.com
Here's a better hack, based on what I'm already doing to workaround this issue:

// define this object in ALL windows you open.
var gui = { Window: { open: (function(uri, props) { if(window.opener != null) { return window.opener.gui.Window.open; } else { return require('nw.gui').Window.open; } })()}};


To open a window, working around the bug/limitation, the usage is the same everywhere:

var win = gui.Window.open('../designB/SynclioLocalUI/menu.html', { frame: true, toolbar: true, width: 590, height: 500, 'always-on-top': true, show: true, resizable: true });

In other words, this recurses back up the chain of opened windows to the top-most window, where nw.gui works as expected. Maybe someone way smarter than me can use this to enhance the feature at the module level. If so, that would be awesome!

Hope this helps, and please let me know if you need any more information to reproduce the actual bug/limitation. I'm happy to help.

James

Laszlo Z. Antal

unread,
Feb 5, 2014, 7:21:43 PM2/5/14
to node-...@googlegroups.com
Hi,

Could you post your package.json file?
Did you use app:// to define main: in it? https://github.com/rogerwang/node-webkit/wiki/App%20protocol

Laszlo

james.m...@a-cti.com

unread,
Feb 11, 2014, 12:46:24 PM2/11/14
to node-...@googlegroups.com
Here's the package.json. I'm not using the app:// protocol in the main property, but I can definitely try that. Although the main issue I'm facing right now is that when I use nw.gui, I lose the window.opener in the child windows. window.opener is null.

{
  "name": "synclio-demo",
  "main": "background/background.html",
  "version": "0.8.1",
  "window": {
    "title": "Synclio Softphone",
    "icon": "designB/images/appIcons/128-synclio-red-icon.png",
    "toolbar": true,
    "frame": true,
    "show": true,
    "width": 800,
    "height": 500,
    "position": "mouse",
    "min_width": 400,
    "min_height": 200
  },
  "dom_storage_quota": 1000,
  "devDependencies": {
    "grunt-node-webkit-builder": "~0.1.16"
  },
  "readmeFilename": "README.md",
  "description": "ERROR: No README.md file found!",
  "dependencies": {
    "grunt": "~0.4.2",
    "grunt-node-webkit-builder": "~0.1.16"
  },
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": "",
  "author": "",
  "license": "proprietary"

sundarasan...@a-cti.com

unread,
Mar 22, 2014, 10:47:46 AM3/22/14
to node-...@googlegroups.com, james.m...@a-cti.com
I too faced the same. Then I manually passed the parent window object to the child window and assigned it to window.opener variable. Now it works fine.
If there is any better solution, please share.

Thanks.
Reply all
Reply to author
Forward
0 new messages