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

Brian Grinstead bgrinstead at
Wed Aug 8 18:28:39 UTC 2018

Filed a bug to remove the pref at <>.

> On Aug 3, 2018, at 7:40 AM, Brian Grinstead <bgrinstead at> wrote:
> Huh - must have missed that during error console removal. I don’t think the pref name fits close enough with this proposed behavior to reuse it, so I’ll file a bug to remove it.
> Brian
>> On Aug 2, 2018, at 7:25 PM, Mike Hommey <mh at> wrote:
>>> On Fri, Aug 03, 2018 at 12:15:50PM +1000, Mark Hammond wrote:
>>>> On 3/08/2018 5:16 am, Brian Grinstead wrote:
>>>> In Bug 1439686 we started printing chrome console messages to stdout. At that time we restricted it to chrome callers to avoid extra noise in stdout during local builds - especially since filtering out content messages is a much-requested feature for the Browser Console (Bug 1260877).
>>>> Interestingly, a page can already get text out to stdout if browser.dom.window.dump.enabled is true using `window.dump`. But the output isn't great when dealing with objects, and it requires the page to change its code.
>>>> We got a request to enable this for console.log in Bug 1480544 - I'm curious if people have opinions on if/how this should be exposed. Should the output be controlled based on the browser.dom.window.dump.enabled pref? Should we have a second pref controlling itf? Something else?
>>> This is tricky. I use dump() more than I'd care to admit - it works well in
>>> content code because you almost never see dump() used in real sites (does
>>> Chrome even support it?), so there's not a huge amount of "spam" in the
>>> terminal. Having dump() output from *both* chrome and content can be very
>>> helpful.
>>> If we also wrote console.log() from content to the terminal, I fear we would
>>> then end up in a situation where content spams the terminal, with the only
>>> mitigation being to flip browser.dom.window.dump.enabled to false - but that
>>> means we also lose dump() output, throwing the baby out with the bathwater.
>>> So my vote would be:
>>> * Leave dump alone - it's basically a firefox-specific easter-egg and no one
>>> seems to mind that content *could* spam the terminal because it almost never
>>> does. (I know this wasn't proposed, but it's worth clarifying imo)
>>> * A new pref that would allow content console.* output to be written to this
>>> terminal. I'd be fine with this defaulting to true wherever
>>> browser.dom.window.dump.enabled does.
>>> Having "dump" in the name of this pref wouldn't be a good option, because
>>> IMO, it should *not* affect the behaviour of dump()
>> There's javascript.options.showInConsole, too, but I'm not sure it does
>> anything these days, despite being defined in all.js, firefox.js and
>> other places, it seems it was made a no-op by the error console removal
>> in bug 1278368.
>> Mike
>> _______________________________________________
>> firefox-dev mailing list
>> firefox-dev at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list