Problem Description

The most recent stable release of NW.js (v0.27.0) gives a JS error message on startup caused by the NWjs plugin.

Attach a Capx

Blank project with the added NW.js plugin.

Steps to Reproduce Bug

• Create new blank project
• Add the NW.js Plugin
• Preview using NW.js v0.27.0

Observed Result

Construct 2 displays the following error message when starting preview:

Javascript error! Uncaught TypeError: Cannot set property 'onchange' of nullhttp://192.168.2.120:50000/NodeWebkit_plugin.js, line 90 (col 35)[/code:g5as70d4]
Console says the following:
[code:g5as70d4]Uncaught TypeError: Cannot set property 'onchange' of null
    at pluginProto.Instance.instanceProto.onCreate (NodeWebkit_plugin.js:90)
    at Runtime.loadProject (preview.js:1482)
    at XMLHttpRequest.xhr.onload (preview.js:414)[/code:g5as70d4]

[b]Expected Result[/b]
It should preview games just like it did in the previous versions.
    
[b]Affected Browsers[/b]
[ul]
    [li] NW.js (YES)
    [/li][li] Chrome: (NO)
    [/li][li] FireFox: (NO)
    [/li][li] Internet Explorer: (NO)[/li][/ul]
    
[b]Operating System and Service Pack[/b]
Win7 SP1, up to date drivers.
    
[b]Construct 2 Version ID[/b]
r249 (beta)

Thank you TheRealDannyyy

I tested your capx with r249 and NW.js 0.26.

...

An interesting thing to me is that "browser resolution" is off from "NW.js resolution", which gives correct numbers.

I've checked with the dev kit with my test and that is giving Browser resolution and that is what actually shown on screen I believe.

For now, we can use the workarounds.

Let's hope Chromium Dev fix this the bug.

And again, thank you for all of this.

I'm more an "artist" type. No idea what github and Chrominum are to be honest.

So it was hard for me to do all this stuff and I felt nobody look into the bug even after my report.

I'm really glad I found this thread and hope those info are helpful people who encounter the same issue.

Sorry that I can't do more but sometimes you can't really workaround bugs and have to wait for the Dev's to fix it.

I'd generally recommend to use a frameless window and offer a way to move the window in the settings menu of your game (that's what I do).

The Chromium Dev's seem to do great work with not doing great work at the moment, so I doubt that we'll see a fix for this anytime soon.

Also thanks for helping me out with testing and giving me feedback, going to post a workaround if I find one.

3rd parties are required as usual, got it. Don't get me wrong, I appreciate knowing about possible downsides but again, I'm not really up for a long debate when it comes to implementing basic features into Construct 2/3 that other engines already support for years.

Obviously the following is my personal opinion but it's really frustrating from a developers side to see that more time is being invested into coming up with reasons against implementing certain things, instead of implementing them (at some point) and satisfying current and future customers.

Gotta find someone who is willing to fix and remove broken features of that 3rd party plugin...

Anyway, thanks for responding to this topic.

For 2D games I'm not clear what the benefit is. You can already go in to fullscreen mode to prevent the mouse cursor leaving the window.

As the post states, especially 2D shooters would benefit from this, preventing the user from aiming off-screen (in windowed mode) or go off-screen on multi-screen setups (in fullscreen mode) because browsers don't have an "exclusive fullscreen" feature available yet.

There are downsides too: if you hide the real cursor and display it in-game, it has a higher latency so will feel laggier, so it's better to simply change the real cursor with one of the existing actions.

I'd appreciate your example regarding this. When testing this feature with the demo, I couldn't notice a high latency at all.

Additionally for security reasons you can't just claim pointer lock right off the bat, you have to gain permission for it in a user gesture.

Not a big deal, pretty much all features which alter user inputs or perform major actions on the web (even fullscreen) require permissions of some sort.

Please note that this isn't a requirement inside NW.js at all and the most more advanced games are being developed for that platform.

It then makes it harder to close the game or multitask, since you are locked inside the game until you exit pointer lock, which I think is slightly obnoxious for casual gaming, especially in a browser.

Just deactivate the lock when the user pauses the game or is inside a menu, also not a big deal.

Ashley I'm sure we both could come up with 100+ reasons for/against this feature but I'd appreciate a simple yes or no.

I'd really like to know if I need to get a 3rd party on board or can count on Scirra to add this feature sooner or later.

[quote:8ivjdyts]The chromium update is scheduled for Dec 5th 2017, I'd really wait for that one instead of going through any trouble caused by rolling back. I guess for now you could try to execute a batch file to kill all processes on application shutdown (if Steam offers a feature like that) or simply execute it using the NWjs plugin when the user is closing the game.

Fair point!

My only worry is I'm using Madspy's Steam4C2 plugin and I'm concerned I'll have to wait around until they support the new version of NWJS.

I totally forgot about that, sadly I can't do much about that part.

Best thing would be to ask him in the forum topic about support for upcoming NWjs versions.

Some of you might already know the following problem.

You're trying to play a 2D shooting game made with Construct, you see an enemy approaching from the edge of the window aaaaaaand your cursor is off-screen.

Believe it or not, there is actually a way to prevent this from happening and the solution is called: Pointer Lock API*

Why does Construct not support this feature yet?

The simple answer is, it does... but not officially. There is THIS unmaintained and broken plugin but this really shouldn't be the solution.

Mouse locking is a common feature available in both native and web based game-engines and Construct 2/3 should support this too.

I know it probably won't be a high priority feature on the ToDo list but I'd appreciate if it could be a priority at all.

Ashley without keeping you away from working on C3 for too long, would you consider updating the mouse plugin with the Pointer Lock API soon?

*More information can be found

HERE.

>

> > TheRealDannyyy First off, thanks for all your hard work with this thread. I commented way back when it first was posted and, now that I'm about to release, it has proved invaluable.

> >

> > Question: I've got a Windows 7 user with "ghost instancing". Is the current best fix to roll back to NW.JS 21.0 before "--in-process-gpu" would bug nw.js?

> >

>

> No problem, trying my best to keep this topic up to date.

>

> Judging by the latest response this has been fixed in NWjs v0.27.0 (currently in beta, stable release probably in December).

> NWjs v0.21.0 should be stable, I'd still create a testing branch on Steam and test it out before using it.

>

I'm hoping to release in the next week or two.

What's the best way to rollback to an old version of NW.JS? I've done it before but I always get a profile error. Familiar with this?

I've never done that before but I guess backing up any local or webstorage files and then deleting all old files using a batch script would work?

(Sorry can't do it on my end so you have to test it out by yourself.)

The chromium update is scheduled for Dec 5th 2017, I'd really wait for that one instead of going through any trouble caused by rolling back. I guess for now you could try to execute a batch file to kill all processes on application shutdown (if Steam offers a feature like that) or simply execute it using the NWjs plugin when the user is closing the game.

TheRealDannyyy First off, thanks for all your hard work with this thread. I commented way back when it first was posted and, now that I'm about to release, it has proved invaluable.

Question: I've got a Windows 7 user with "ghost instancing". Is the current best fix to roll back to NW.JS 21.0 before "--in-process-gpu" would bug nw.js?

No problem, trying my best to keep this topic up to date.

Judging by the latest response this has been fixed in NWjs v0.27.0 (currently in beta, stable release probably in December).

NWjs v0.21.0 should be stable, I'd still create a testing branch on Steam and test it out before using it.

I've always had this issue with Construct 2 on my end. Usually grabbing a cup of coffee during the wait.

Using the Steam version and it takes about 15 seconds when starting C2 for the first time. (4-6 seconds for all starts after the first one.)

TheRealDannyyy

Sorry for the late reply, I finally got around to do what you suggested: uninstal NW.js and "reset" the manifest files.

I also uninstalled and reinstalled C2. Just in case I deleted 3rd party plugins and behaviors too.

To be clear, I tested with r247, NW.js 0.26 downloaded from Scirra's page and win7/10 64bit on desktop PC....

Sorry for the late reply as well. First things first, no need to re-install NW.js or do something like that, it's not necesarry.

I know I'm late and the most stuff is already known on Github but below you can check out my findings and experiment around yourself.

My Observation:

Using the information from Github it's clear that Chromium has an issue with non-resizable windows (+high DPI display). From my tests, this issue is not only affecting high DPI displays but also regular displays. Feel free to test it out on your end and post your results.

My Tests:

Files & Requirements:

• NW.js V0.26.0 (Download)
• Updated Testing Project (Download)
• Construct 2 r249+

Issue #1 - Window Size Issue (Exported Version):

• Set "Use high-DPI display" to YES/NO
• Export your project (Window Frame: YES | Resizable Window: NO | Kiosk Mode: NO)
• Notice incorrect window size regardless of the DPI setting

Issue #2 - Not Resizable Action Is Broken (?):

• Preview the project (in-editor or exported, doesn't matter)
• Enable advanced settings
• Click on "Resizable Window OFF"
• Try to resize the window (should be possible even though it's disabled)
• Click on "Resizable Window OFF" and notice that you can resize it again

Last Words:

I've included a possible workaround that you can try out but it's not perfect and "hacky", that's why the event-structure might look a bit weird at first.

I might post a reply in the Github thread with all the new information soon but for now we have to wait for the Chromium Dev's to do their work.

Ashley Could you please look into this and fix it in or before the next stable update.