Phantomjs: Redirect console.error to stderr

[gseguin]

_[email protected] commented:_

Which version of PhantomJS are you using? 1.1 and 1.2

What steps will reproduce the problem?

1. Have a webpage with console.error calls in it

What is the expected output? What do you see instead?
All output comes to stdout

Which operating system are you using?
*NIX (OSX and Linux)

Did you use binary PhantomJS or did you compile it from source?
Both

Disclaimer:
This issue was migrated on 2013-03-15 from the project's former issue tracker on Google Code, Issue #150.
:star2:   13 people had starred this issue at the time of migration.

[ariya]

_[email protected] commented:_

Pretty easy to do. I'll take the job.

 
_Metadata Updates_

• Owner updated: [email protected]

[ariya]

_[email protected] commented:_

 

 
_Metadata Updates_

• Status updated: Accepted

[ariya]

_[email protected] commented:_

This is not easy. Currently QtWebKit does not provide an API to distinguish between different console.* invocation.

 
_Metadata Updates_

• Milestone updated: FutureRelease (was: ---)

[ariya]

_[email protected] commented:_

Ah. Guess I was misguided. ;)

 
_Metadata Updates_

• Owner updated: ---

[detro]

_[email protected] commented:_

Hello,

yesterday, while putting together the REPL, I took a look again to the implementation of "Phantom::printConsoleMessage". I noticed a pretty simple thing, that I'm sure has come to mind before, but never acted on it.

At line 230 (https://github.com/ariya/phantomjs/blob/master/src/phantom.cpp#L230) we are detecting if there is a "source" provided by WebKit and, if so, print a slightly reacher message, based on that.

This makes me think that we do have a "smart-ass" way to distinguish between normal output and ERRORs. We could "split" the output based on the fact that the WebKit core is providing a file and line position or not.

Of course, I think this does NOT cover console.error()... unfortunately :(

Should we put this split in place for now? The consequence, I guess, is that "console.log" and "console.error" will still come out from the same STDOUT, but actual JS errors in the code will be detected and, therefore, possible to manage.

Maybe even introducing some console coloring (where supported).

What do you think?

[ariya]

_[email protected] commented:_

It would also be great, if it could print out the location of any javascript errors. That would make debugging a lot easier.

[detro]

_[email protected] commented:_

Should we go ahead and start to do "some" filtering based on the presence of "sourceId" and "lineNumber" in the callback?

To complete the picture (redirect JS calls to "console.error") we could, "simply", override the console object.

[JamesMGreene]

_[email protected] commented:_

I'd like to take this one but I'm a bit busy this month.

Nevertheless, I thought I'd take a minute to drop a reminder that writing to the stderr stream can be achieved cross-platform much more easily now with the changes made for Issue #10333 -- at least for console.error messages in the PhantomJS outer space.

On that last note, I personally am of the opinion that WebPage client-side console.error messages should be handled differently anyway... I don't want those going to my stderr stream at all! I've got something cooked up for that locally that I'll try to share by the end of the month but the way I implemented it was with a new events API written on top of the existing API.

[JamesMGreene]

_[email protected] commented:_

Initial commit of aforementioned events API: https://github.com/JamesMGreene/phantomjs-extensions/

It was originally written against 1.6 or 1.7 and I haven't updated the code to align with changes since then (e.g. Ivan added an internal event for "onOpened", Vitaliy added an event for onResourceError, etc. It isn't dissimilar to what CasperJS does but it does dig much deeper, e.g. overriding the WebPage window's console to enable distinguishing between the various console methods, etc. Would love some feedback, thanks!

[metaskills]

This should be do'able now in 1.9 by doing the following?

• Override the console.log and console.error and have it send the string to window.callPhantom along with a data hint.
• Have the onConsoleMessage handler figure out what message is being sent, then send errors to system.stdout.

[JamesMGreene]

@metaskills: Quite right.

So now the question is: should the default behavior be for console.error [in the PhantomJS outer context] to write to stderr or should we leave it as-is and just allow the user to decide on using an approach like the one @metaskills mentioned?

cc: @ariya @detro @execjosh

[JamesMGreene]

@ariya @detro @Vitallium @execjosh: Any opinion on the question I posed in the previous comment here?

[execjosh]

@JamesMGreene: I don't use console.error very often; but, if the main use case is error reporting, then having it automatically go to STDERR would allow for easy muting (e.g., 2> /dev/null in bash-like shells).

[Delapouite]

I've also been bitten by this one, expecting console.error writing to stderr like in node.

[briangordon]

I've been bitten!

[sodabrew]

Yep, me too. Console.error should go to STDERR. It just makes sense.

[cburgmer]

Here's a monkey patch solution for the meantime:

console.error = function () {
    require("system").stderr.write(Array.prototype.join.call(arguments, ' ') + '\n');
};

[sgri]

I would like to move to stderr errors like these:

• CLIENT: Exception thrown by mediawiki.page.ready
• CLIENT: TypeError: 'undefined' is not a function (evaluating '$content.find('.mw-collapsible').makeCollapsible()')

[gustavohenke]

@cburgmer your solution is working fine for now, but it would be much better if this could simply be implemented in Phantom core.

[zackw]

Confirmed to still be an issue in 2.0:

$ cat test-cerr.js
console.log("This should go to stdout");
console.error("This should go to stderr");
phantom.exit(0);
$ ./bin/phantomjs test-cerr.js 2> /dev/null
This should go to stdout
This should go to stderr

  :0 in error

[kawing-chiu]

There is also console.warn. In node, it is directed to stderr too.

[sudotliu]

@kawing-chiu, even with console.warn, it seems like you would still have to apply the same hack with something like:

console.warn = function () {
    require("system").stderr.write(Array.prototype.join.call(arguments, ' ') + '\n');
};

Did you actually find a shorter way to do it?

[kawing-chiu]

@sudotliu No. I think your method is quite good and I've been using it for while. :)

[itbdw]

bug still exists at v2.1.1
These hot patch saved me!

console.warn = function () {
    require("system").stderr.write(Array.prototype.join.call(arguments, ' ') + '\n');
};

console.error = function () {
    require("system").stderr.write(Array.prototype.join.call(arguments, ' ') + '\n');
};

[ariya]

Due to our very limited maintenance capacity (see #14541 for more details), we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed. In the future, if we see the need to attend to this issue again, then it will be reopened.
Thank you for your contribution!