Closed
Bug 1175318
Opened 9 years ago
Closed 9 years ago
Calls to console.log() don't show up in stdout
Categories
(Testing :: Mochitest, defect)
Testing
Mochitest
Tracking
(firefox42 fixed)
RESOLVED
FIXED
mozilla42
Tracking | Status | |
---|---|---|
firefox42 | --- | fixed |
People
(Reporter: bgrins, Assigned: bgrins)
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
past
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•9 years ago
|
||
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");
});
Assignee | ||
Comment 2•9 years ago
|
||
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.
Attachment #8623332 -
Flags: review?(ted)
Comment 3•9 years ago
|
||
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.
Attachment #8623332 -
Flags: review?(ted) → review+
Assignee | ||
Comment 4•9 years ago
|
||
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
Assignee: nobody → bgrinstead
Attachment #8623332 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8628574 -
Flags: review?(past)
Comment 5•9 years ago
|
||
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?
Attachment #8628574 -
Flags: review?(past) → review+
Assignee | ||
Comment 6•9 years ago
|
||
(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.
Assignee | ||
Comment 7•9 years ago
|
||
Whiteboard: [fixed-in-fx-team]
Comment 8•9 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox42:
--- → fixed
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → mozilla42
You need to log in
before you can comment on or make changes to this bug.
Description
•