Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

console.log from node modules #196

Closed
AlgoTrader opened this Issue · 23 comments

4 participants

@AlgoTrader

I see the strange behavior. If module installed in node_modules contains console.log, my app "hangs" , gray screen is shown and debugger go unresponsive. console.log in webkit side works just fine.

After removing console.log from node libs app returns to work. What may cause hang while printing console.log from node.js side?

@AlgoTrader

Hint: Uncaught Error: Implement me. Unknown stream file type!
I saw it in debugger

@rogerwang
Owner

Hello, please see #184.

@rogerwang
Owner

And the gray screen should be that the process quits on the uncaught error.

@rogerwang
Owner

@zcbenz we need to check why this lead to a crash.

@AlgoTrader what's your OS version? Thanks in advance.

@AlgoTrader

Yes, exactly. That's throw, but the window is alive, just go gray and unresponsive (bar is working). It would be great to have a meaningful error message, not just unresponsive gray screen (can we redirect to a message error page?)

You are right, it's windows. The next question is what to do. The current default behavior is pretty unreasonable. It would be better to just to redirect console.log to some null device. Any hints of how to survive?

Want to say it is the great project, thank you guys.

@AlgoTrader

It's Win 7 64 bit. I can reload the URL and things go work again (starting from point zero). Sometimes throw cause error in debugger and sometimes cause gray screen. I think throw handling is different in node and webkit. Do you need other info on the issue? In direct call of node module method is prints the Uncaught error, in callbacks it hangs, I believe. it is my current vision.

@jeroenransijn

I am experiencing the same issue, and it's getting really annoying. Console.log won't work for me, if called from a node context. I am on Mac OS X Mountain Lion. I get a grey screen, also my debugger window will detach.

@rogerwang
Owner

For a workaround you can just redefine console.log to your own function.

@rogerwang
Owner

@AlgoTrader the window and the web page content are from different process.

@rogerwang
Owner

@AlgoTrader can you show your code where "in callbacks it hangs"? Thanks

@AlgoTrader

Checked the process list. There was single process in list, window process I think. After reloading URL in bar, there were two processes again. So it is clear. node throws at console.log and process quits. Next question is how to make console.log working more reasonable then now

@AlgoTrader

It is pretty big, it's quite big npm module with thousands of lines. I would try console.log in process.netTick and setTimer callbacks. Mine crash is in callback of TCP connection (the SOAP response), but I don't think it's related to TCP

@AlgoTrader

So the minimalistic reproduce:

//console.log("This cause a message in debugger");

process.nextTick( function() {
console.log("this causes gray screen");
})

Including this module cause gray screen at require. After uncommenting of first line just shows throw in debugger

@rogerwang rogerwang closed this in d41b9ea
@rogerwang
Owner

The crash has been fixed with the previous commit. Will be released in 0.3.4. Thanks for reporting.

@zcbenz zcbenz referenced this issue from a commit
@zcbenz zcbenz [Test] Test case for #196. 5da41a2
@nathansobo

When I call console.log from a WebKit module with version 0.3.4 on OS X, it doesn't crash but I also don't see any output in the development console. Is this the expected behavior?

@nathansobo

I wrote the following simple module as an experiment:

// require-me.js
module.exports.console = console;
module.exports.windowConsole = window.console;

Then I require the module from the developer tools, and try calling functions on each of the exported consoles:

module = require('./require-me');
module.console.log("Testing") // nothing happens
module.windowConsole.log("Testing") // prints testing to the developer tools console

console.log(module.console.log.toString()) // output below, looks like Node's implementation of console.log, not WebKit's
/* 
function () {
  process.stdout.write(util.format.apply(this, arguments) + '\n');
}
*/

It seems like global.console isn't being properly overridden with WebKit's in the node module's context. Was this fixed prior to 0.3.4?

Thanks! :factory:

@rogerwang rogerwang was assigned
@rogerwang
Owner

I can confirm this. Will fix it. Thanks for reporting.

@rogerwang rogerwang reopened this
@rogerwang
Owner

@nathansobo , I just checked it again. On Linux and Mac 'console.log' is not supposed to be replaced by the one from WebKit, because the console works on these 2 platforms, and you should see the log text printed on your console. On windows, since a GUI application doesn't have a console, we replaced the Node's implementation with Webkit's.

@rogerwang rogerwang closed this
@nathansobo

@rogerwang I can see the logic in that, but for our use case at least, it would be better to have everything log in the developer tools. Our current application, based on CEF, has its own version of require that loads all our application code synchronously. We really like this design, as it allows us to use Node's model of synchronously requiring our code, rather than relying on script tags, concatenation, etc. But that means that 99.999% of all our code is loaded via require, not just a subset of it that's the Node modules. This means it's important that code that's loaded with require behaves the same way as code that's loaded with a script tag.

@rogerwang
Owner

I see. And it's reasonable to keep the uniform behavior across the supported platforms. will fix it.

@rogerwang rogerwang reopened this
@rogerwang rogerwang referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@rogerwang
Owner

close with the previous commit.

@rogerwang rogerwang closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.