Internet Explorer won't load all of Node-RED after enabling 'natural-language-understanding'.

[hthomann]

HI! I opened an issue [1] a few weeks back which was mostly ignored given some poor (vague) languages choices on my part (i.e. I made it sound like the issue might not be related to node-red-node-watson). However, let me explain a recreate that will show that by simply enabling or disabling 'natural-language-understanding' will cause Internet Explorer (IE) to not be able to load Node-RED (NR). Furthermore, I’ve narrowed down the exact version where the issue starts to occur. That is, my recreate doesn’t occur on 0.5.13, but starts to occur on 0.5.14 and after. It makes sense that it would start to fail on .14 since I see in the .14 release comments that changes were made to natural language. Here is the recreate:

1) Do an ‘npm install node-red-node-watson@0.5.13’ to install version .13. 2) Start IE and open NR. 3) Go to Manage Palette and find node-red-node-watson. Make sure the version is 0.5.13 and that all nodes are enabled. 4) Uninstall the Watson nodes (i.e. ‘npm uninstall node-red-node-watson’). 5) Do an ‘npm install node-red-node-watson@0.5.14’ to install version .14. 6) Start IE (or reload the browser from #2) and open NR. 7) NR will likely not fully load. 8) Go to Manage Palette and find node-red-node-watson. Make sure the version is 0.5.14. 9) Find 'natural-language-understanding' and disable it. 10) Reload the IE browser, and now NR will load fully.

This seems to be very specific to the Watson nodes and should be looked into. Please don’t response with “don’t use IE”. Unless there is documentation stating NR doesn’t support IE (which would be a shame since IE is still in use), I feel this needs to be fixed.

[1] https://github.com/watson-developer-cloud/node-red-node-watson/issues/352

Sincerely,

Heath Thomann

[chughts]

I don't have a windows machine, so am unable to verify this, so will need you to carry out some additional tests for me.

I believe this is related to a bug that was introduced in version 14 and fixed in 21. It relates to how the node checked for binding and endpoint verification. It was actually asking the Discovery Node, rather than the NLU Node. In most other browsers this check failed with a service not found error, and the node erred in how it prompted for service credentials.

To verify if this is the case, can you test by first adding a Discovery node to a flow, then a NLU node. Then move to the latest version, currently 23, and try to reproduce your original scenario.

If I was to apply a fix it would go into a release after 23 in any case, as I can't apply a retrofix to 14.

[hthomann]

HI! First, did you notice that I said "....my [issues] doesn’t occur on 0.5.13, but starts to occur on 0.5.14 and after"….note “and after”. So, the issue does occur on .14 all the way up to the latest (.23). Furthermore, I don't intend for this to be fixed in any older releases. I was simply trying to help you out by letting you know where things work and fail (i.e. it is often times much easier to narrow in on the specific changes in a release where things start to fail).

Finally, I'd gladly try your test but let me make sure it is clear that I'm not even using any of the watson nodes in flows. That is, I have removed my flow file so I have NO flows (initially I thought maybe I did something incorrectly in my flow so wanted to rule out any issues with a bad flow). With no flows, I then go forth with the recreate I described above. Therefore, I'm technically not even using any of the watson nodes. Since they are not in my flow, are they really doing any work as you suggest? However, I’ve tried your scenario as follows: using version .23, I open NR in FireFox (keep in mind that with NLU enabled, I can’t bring up NR in IE so I have to use FF to be able to add the nodes to my flow). I then simply add (drag and drop) a Discovery node and NLU node into my flow and deploy. I don’t configure these nodes (sorry, I’ve never used them so I don’t know how to do so, nor do I have the time to do so). I then open IE and access NR. Doing so the issue is the same: NR won’t fully load in IE.

By the way, I’m including a screen capture of how NR looks in IE when it won’t load.

Sincerely,

Heath Thomann

[chughts]

I see that you are running node-red locally, in which case can you look at the node-red console and see if any related messages are being logged.

Could you also open up the IE equivalent of the developers javascript console and see if any javascript or network errors are being reported.

[hthomann]

HI! I'm on vacation this week. This weekend or early next week I'll write up what I see in the IE developer tools and post that here.

Thanks, Heath Thomann

[hthomann]

HI! I'm on vacation this week. This weekend or early next week I'll write up what I see in the IE developer tools and post that here.

Thanks, Heath Thomann

[hthomann]

HI! I turned on level: “trace” in my settings.js and I do not see anything of interest come to the console…..that is, I do not see anything additional between the case where NLU is disabled or enabled (i.e. the console looks the same in both cases). If there are additional logs I should look at please let me know. However, using the “developer tools” in IE, I do see some differences. I can’t make any sense of the differences, but maybe you can as the developer. Let me state some findings, however ultimately I think you are going to have to find a windows machine and debug for yourself (as a former IBMer, I know that IBM has a variety of VMs with many different types of OSs; you should track down a windows machine). I don’t mind helping out and collecting info for you, I’m just not sure if it is the most efficient means of debug.
Anyway, let me start my analysis. As the first screen cap shows, when NLU is enabled, and I load NR, the last things I see in the ‘network’ tab is ‘debug-utils.js’:

If I disable NLU I see more stuff after the ‘debug-utils.js’ call. Also note in the first screen cap that, at the bottom (which is the console view) you can see that the error is “SCRIPT1006: Expected ')' vendor.js (2,2615)”. I think this is reporting the end result, and nothing which lead up to, and caused, the error. In the dev tools debugger view, I change the ‘break’ option to ‘break on unhandled exceptions’. Doing that, I can see where the exception occurs. That is, I reload the NR editor and see when/where the exception occurs. This can be seen in this screen cap:

At this break point, the call stack is:

[Main Thread] a.execScript [Line: 82, Col: 13], vendor.js globalEval [Line: 81, Col: 28], vendor.js domManip [Line: 1592, Col: 148], vendor.js append [Line: 1518, Col: 9], vendor.js success [Line: 16, Col: 259], main.min.js j [Line: 900, Col: 17], vendor.js k.fireWith [Line: 935, Col: 13], vendor.js x [Line: 2321, Col: 577], vendor.js b [Line: 2443, Col: 26], vendor.js

There is a lot going on in screen cap 4. Notice that I highlighted ‘b’, and then highlighted its message. Notice that the code in ‘b’ seems to have a lot to do with NLU. The code in ‘b’ appears to be coming from $NODE_HOME/node_modules/node-red-node-watson/services/natural_language_understanding/v1.html

I hope this is enough to allow you to make progress. Let me know if I need to provide any additional debug.

Sincerely,

Heath Thomann

[chughts]

@ChrisParsonsDev This appears to be pointing at the javascript in the html file for the natural language understanding node. I have taken a look at the code, and as far as I can see all braces and brackets match.

I have a mac with Node-RED 0.17.4 and Node.js 6.11.2 and the latest cut of the Watson Nodes. I don't see this error in the console for Safari, Chrome or Firefox.

[ChrisParsonsDev]

@hthomann This issue is actually caused by Default Parameters. These allow us to set the way we handle undefined variables within the JavaScript code for our nodes. The way we choose to implement our nodes, using Default Parameters, is compliant with ECMAScript 6 specification. Unfortunately as of today Internet Explorer does not support ES6, the latest specification supported by IE is ES5. As a result - we can't commit to Internet Explorer support until IE supports ES6, as the other modern browsers do. For the meantime please use an ES6 compliant browser (Firefox, Chrome, Safari etc.)! I know this isn't the answer we wanted, but I hope this stop gap of using a different browser until we get ES6 support in IE is acceptable.

[hthomann]

@ChrisParsonsDev HI! Thanks for you investigation and response. Well, Eclipse SWT 'Browser' uses IE by default (need to investigate this and see if Eclipse will move to Edge or something since IE seems to be dying). So we are stuck with IE. However, answer me this: why does this ONLY happen with NLU node enabled and not with the other 40 nodes in Watson?

Thanks,

Heath Thomann

[chughts]

Fixed in 0.6.0

[hthomann]

@chughts HI! Thank you so much for fixing this! I can now open Node-RED in IE with the NLU enabled!! If I could trouble you one last time, I see a nearly identical issue in a package called 'node-red-contrib-iot-virtual-device' (this is in the ibm-watson-iot, so it is likely a corporate cousin of watson-developer-cloud). I know you do not own this package, but the symptoms seem to be the same (i.e. the error stack seems identical to the ones I posted above for this issue.). I wonder if you could be the good open source citizen that you are and post here HOW you fixed this issue, or point to the source code with the fix. :) In this way, the developer in 'node-red-contrib-iot-virtual-device' might be able to fix their issue easily and quickly. If you care to look, I have opened the following issue against the package here:

https://github.com/ibm-watson-iot/node-red-contrib-iot-virtual-device/issues/5

Sincerely,

Heath Thomann