1175318 - Calls to console.log() don't show up in stdout

Status: RESOLVED FIXED

(Testing :: Mochitest, defect)

Description

[Brian Grinstead [:bgrins]]

If I have a mochitest-browser file like:

add_task(function* () {
  console.log("Hello");
});

Then the log statement doesn't show up in stdout.  It can be seen in the Console tab of the Browser Toolbox if the test is run with the --jsdebugger flag, but it'd be great to see it in the dump output as well.

Comment 1

[Brian Grinstead [:bgrins]]

If console is imported from Console.jsm the logs show up in both places:

add_task(function* () {
  const {console} = Components.utils.import("resource://gre/modules/devtools/Console.jsm", {});
  console.log("Hello");
});

Comment 2

[Brian Grinstead [:bgrins]]

Attachment: console-log-mochitest.patch

This fixes the problem for me.  What do you think about it?

I'm not sure if this will cause any issues with logging format (console.log statements from Console.jsm aren't prefixed with TEST-INFO for example, although that would be an easy change if needed).  In most cases console.log statements would just be used for debugging locally, and would be removed or replaced with info() calls before landing anyway.

Comment 3

[(not currently active) Ted Mielczarek]

Comment on attachment 8623332 [details] [diff] [review]
console-log-mochitest.patch

Review of attachment 8623332 [details] [diff] [review]:
-----------------------------------------------------------------

This seems fine, it's no worse than sticking dump() in there, and might capture some existing in-product debug prints.

Comment 4

[Brian Grinstead [:bgrins]]

Attachment: console-log-mochitest.patch

Panos, can you take a look at the test fixes I needed to make to get a green run in browser_ConsoleStoragePBTest_perwindowpb.js and test_basics.html?  In both cases the test was expecting the browser window to have calls to the native console API to happen but since the browser-test overlay is active it's now inserting into ConsoleAPIStorage with the "jsm" id.

Pushed to try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9773f8a7a9e5

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

Comment on attachment 8628574 [details] [diff] [review]
console-log-mochitest.patch

Review of attachment 8628574 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/devtools/webconsole/test/test_basics.html
@@ +44,5 @@
>          "startedListeners: ConsoleAPI");
>    is(startedListeners.indexOf("foo"), -1, "startedListeners: no foo");
>    ok(!aResponse.nativeConsoleAPI, "!nativeConsoleAPI");
>  
> +  top.console = top.console_;

Why do we need to do this here as well, if it is already being taken care of in onStartConsoleAPI later on?

Comment 6

[Brian Grinstead [:bgrins]]

(In reply to Panos Astithas [:past] from comment #5)
> Comment on attachment 8628574 [details] [diff] [review]
> console-log-mochitest.patch
> 
> Review of attachment 8628574 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: toolkit/devtools/webconsole/test/test_basics.html
> @@ +44,5 @@
> >          "startedListeners: ConsoleAPI");
> >    is(startedListeners.indexOf("foo"), -1, "startedListeners: no foo");
> >    ok(!aResponse.nativeConsoleAPI, "!nativeConsoleAPI");
> >  
> > +  top.console = top.console_;
> 
> Why do we need to do this here as well, if it is already being taken care of
> in onStartConsoleAPI later on?

Because the aResponse.nativeConsoleAPI inside onStartConsoleAPI requires that the tab doesn't have a special console object defined.  And since we are now attaching the console to the tab for onStartConsoleAPI, resetting that causes aResponse.nativeConsoleAPI to have the correct value.  We probably don't need to *also* reset it inside of onStartConsoleAPI though.

Comment 7

[Brian Grinstead [:bgrins]]

remote:   https://hg.mozilla.org/integration/fx-team/rev/490adfa725c1

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/490adfa725c1