Output in Chrome console includes "stdout:"-prefixed lines

[mattflix]

Mocha 2.4.5
Chrome 48.0.2564.103

Pretty much with any reporter I use, Mocha outputs the following poorly-formatted text to the browser console.

Note the weird "stdout:"-prefixed lines.

  Foo
     #bar
 stdout: [2K
       1) should work
       ✓ should still work
   1 passing (770ms)
   1 failing
   1) Foo #bar should work:
     Error: oops
      at Context.shouldWork (test/test.js!transpiled:11:35)

 stdout: [0G
 stdout: [2K
 stdout: [0G

This seem to be the result of code in most reporters using a combination of calls to console.log() and process.stdout.write(). In the browser, process.stdout is ultimately implemented as calls to the console with "stdout:" prefixed in front on each line (not really sure why, just something BrowserStdout does) which is often just a cursor movement escape code (which, in many cases, like above, really contributes nothing to the final formatting).

So, this just doesn't work well, eh? Can something be done to make reporter output look better in the browser? Mocha is advertised as working "in the browser" ...but it doesn't really.

[ebbe-brandstrup]

I'm getting the same. It is really spamming the output.

Not only in the browser btw. I am using dispatch:mocha-phantomjs and stdout: [0Gandstdout: [2K` are getting spammed into the terminal output as well as the browser console.

[skeggse]

This will be partially resolved by #2373, but there will still be a bunch of lines (albeit blank lines) in the output. This is due to the choice of browser-stdout for process.stdout in the browser. The module is problematic for mocha's uses for two reasons:

• it buffers output, and some of the code just uses console.log, so the output isn't interleaved as intended
• it outputs each chunk as a new line, so there are many more newlines than there should be

[boneskull]

@skeggse I don't know why browser-stdout is required. Is there an alternative?

[boneskull]

I'm going to call this a "bug".

[boneskull]

So, this just doesn't work well, eh? Can something be done to make reporter output look better in the browser? Mocha is advertised as working "in the browser" ...but it doesn't really.

The "intended" browser reporter is the HTML reporter, and it's no work of art, but it's decent. 😏

[skeggse]

@boneskull I didn't find a good alternative. A real alternative would overwrite the global console methods, and add a global process shim.

[mattflix]

Isn't the alternative to log everything via the same conduit? Right now, the hodge-podge of calls to console.log() and BrowserStdout (delayed on timers) is what is causing the mess in the browser console.

[skeggse]

Correct, everything could go out through process.stdout. Alternatively, we could add a buffer mechanism to mocha to buffer partial lines.

[plroebuck]

I'm getting the same. It is really spamming the output.

Not only in the browser btw. I am using dispatch:mocha-phantomjs and stdout: [0Gandstdout: [2K are getting spammed into the terminal output as well as the browser console.

Could you verify this problem still happens using Mocha-5.2 in your test environment?

[plroebuck]

PR #2373 had a bug which left the stdout: prefix intact.
PR #3477 corrects that problem.

My tests confirm that the prefix is gone afterwards. I find no evidence of terminal control codes in spec reporter output. Obviously, some reporters (e.g., nyan, landing) are lost causes for the browser console.

Appears that the terminal spew might have come from play/stop methods (originally used with
--watch that displayed "watching" string onscreen, then later a text "spinner"). Looks like
the spinner itself was removed in late 2013, but those methods hung around until removed in #3418.
Guessing they were somehow actively writing terminal sequences without any associated text.

Plan to close this (again, for good) when #3477 is merged.

If you still experience the terminal control code spew problem, open a new issue.
And be prepared to explain how to reproduce it...

[outsideris]

close by #3477