Should we make content console messages print to stdout when browser.dom.window.dump.enabled is true?

Brian Grinstead bgrinstead at
Mon Aug 13 17:01:53 UTC 2018

> On Aug 13, 2018, at 8:36 AM, Andreas Tolfsen <ato at> wrote:
> Hi, sorry for chiming in late.
> dump() is used extensively for logging through Log.jsm, and that
> again is used in a lot of our test automation.

`dump` behavior won’t change regardless of any changes here.

> Also sprach Brian Grinstead:
>> Based on the discussion here and on the bug, I do think there’s
>> value in being able to separately control chrome and content logs
>> going to stdout. I’m leaning towards either:
>> 1) Keep the current behavior for chrome callers and then add a
>> second pref (false by default everywhere) to allow content logs to
>> go out to stdout.
> Sorry, maybe this is a stupid question, but what exactly is a “chrome
> caller” and how is it differentiated from a JSM using dump()?

This is referring to chrome callers (i.e. JSMs or any other chrome-priv JS code) of `console.log` (distinct from callers to `dump`). FWIW for most cases, I’d recommend to use console.log() in chrome code instead of dump() - it shows up in the Browser Console, does a better job of formatting objects, and supports multiple arguments.

>> 2) Stop overloading `browser.dom.window.dump.enabled`, and instead
>> add two new prefs like `` and
>> `devtools.console.stdout.content`. The chrome variation would be
>> true by default in local builds and automation, I guess, and the
>> content variation would be false by default everywhere.
> Being able to differentiate between web content uses of window.dump()
> and those originating from privileged JS seems reasonable, but why
> devtools.console.*?  Is dump() specific to devtools?

This would only affect callers of `console.log`. It’s all a bit confusing though, since we are currently overloading the dump pref (browser.dom.window.dump.enabled) to also print chrome `console.log` messages to stdout. The idea of creating `devtools.console` prefs is to (a) stop that overloading, and to (b) give more fine-grained control over what goes out to stdout. I don’t feel too strongly about (a) - if we wanted to continue overloading the dump pref for that it'd be fine with me. But I think (b) is necessary to prevent spamming stdout with content console.log messages when the dump pref is set.


More information about the firefox-dev mailing list