evothings / evothings-studio

Evothings Studio
http://www.evothings.com/
Apache License 2.0
53 stars 33 forks source link

Uncaught node.js Error when client connects while Welcome- or Tools window is visible #53

Closed TechWizEric closed 9 years ago

TechWizEric commented 9 years ago

ETS 1.0.0 through 1.1.0 RC2, but not e.g. v. 0.7.3, displays an Uncaught node.js Error in the Workbench window and freezes when a client connects while the Welcome- or Tools window is visible.

This has been observed in OS X 10.10.1 and Windows 8.0. This is believed to occur due to that the scope within which the scripts are run is changed and this must be handled either in node-webkit or by us.

The issue does not occur if a data folder (e.g. ~/Library/Application Support/Evothings Workbench) from an older version (<1.0.0) of Evothings Workbench is present.

Steps to reproduce:

  1. Disconnect all clients.
  2. Launch Evothings Workbench
  3. Open the Welcome screen (either automatically or manually).
  4. Connect to the workbench from ETC or another browser.

Actual result: Workbench window shows "Uncaught node.js Error" (see screenshot below).

Uncaught node.js Error

TypeError: Cannot read property 'log' of undefined at Namespace. (/Users/eric/Downloads/EvothingsStudio_Mac_64_1.1.0 RC/hyper/server/hyper-server.js:750:10) at Namespace.EventEmitter.emit (events.js:104:17) at Namespace.emit (/Users/eric/Downloads/EvothingsStudio_Mac_64_1.1.0 RC/node_modules/socket.io/lib/namespace.js:205:10) at /Users/eric/Downloads/EvothingsStudio_Mac_64_1.1.0 RC/node_modules/socket.io/lib/namespace.js:172:14 at process._tickCallback (node.js:382:11)

screen shot 2014-12-16 at 11 31 12

Expected result: Workbench launches correctly and displays projects list.

TechWizEric commented 9 years ago

The issue seems to occur even after restarting the workbench, when activating the Tools window, but it did not occur before the initial deletion of the application's data folder.

ghost commented 9 years ago

Tested with RC2 on OSX 10.9 and the error did not reproduce.

ghost commented 9 years ago

The error can be reproduced by having an Evothings Client running that is connected to the Workbench:

  1. Start Workbench
  2. Connect from Evothings Client
  3. Close Workbench
  4. Start Workbench --> the above error occurs

When you have removed the existing data folder the Workbench crashes as soon as a client connects.

Works with the original data folder.

ghost commented 9 years ago

This turns out to be a problem caused to console being undefined when another window is open.

In context "global" console is undefined, it is defined in context "window". When another window is open it seems the code that crashes is using the context "global".

This commit fixes the problem:

https://github.com/divineprog/HyperReload/commit/9f84d15fff94c4fde8db949fe0c38f3c2beaeb5c

TechWizEric commented 9 years ago

Tested build of ETS including the fixes in https://github.com/divineprog/HyperReload/commit/9f84d15fff94c4fde8db949fe0c38f3c2beaeb5c . The issue remains, and the following error is shown.

Uncaught node.js Error

TypeError: Cannot read property 'log' of undefined at GetFileStatus (/Applications/EvothingsStudio_Mac_64_1.1.0 RC/hyper/server/webserver.js:369:10) at ServeFile (/Applications/EvothingsStudio_Mac_64_1.1.0 RC/hyper/server/webserver.js:295:14) at Server.HandleRequest (/Applications/EvothingsStudio_Mac_64_1.1.0 RC/hyper/server/webserver.js:289:3) at Server. (/Applications/EvothingsStudio_Mac_64_1.1.0 RC/node_modules/engine.io/lib/server.js:369:22) at Server. (/Applications/EvothingsStudio_Mac_64_1.1.0 RC/node_modules/socket.io/lib/index.js:258:16) at Server.EventEmitter.emit (events.js:107:17) at HTTPParser.parserOnIncoming as onIncoming at HTTPParser.parserOnHeadersComplete (_http_common.js:111:23) at Socket.socketOnData (_http_server.js:357:22) at Socket.EventEmitter.emit (events.js:104:17)

fredrikeldh commented 9 years ago

That line reads console.log('GetFileStatus exception: ' + ex), so if you don't have a console, it would fail.

A thought: wouldn't it be better to ensure that console is always defined?

ghost commented 9 years ago

Yes it would be best to ensure console is defined.

Current solution is to specify context by using window.console which we assume is always defined. But it would be better (more safe) I guess to do something like:

if (!window.console) { window.console = {} }
if (!window.console.log) { window.console.log = function(message){} }
ghost commented 9 years ago

This is the commit that updates the code to use window.console where it is needed: https://github.com/divineprog/HyperReload/commit/7f8580a52ac22c716a35eca428803d8f44bca3cd