<div dir="ltr"><div dir="ltr"><div dir="ltr">To follow up on this, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1480544">https://bugzilla.mozilla.org/show_bug.cgi?id=1480544</a> has now landed, which has decoupled Console printing from the dump pref. To sum up:</div><div dir="ltr"><br>* browser.dom.window.dump.enabled continues to enable the dump() function in windows, workers and worklets, and the default values have remained unchanged.<br></div><div dir="ltr"><br></div><div dir="ltr">2 new prefs were added to control printing of Console API calls:</div><div dir="ltr"><br></div><div dir="ltr">* devtools.console.stdout.chrome enables the stdout logging in console API when used in chrome contexts. It is defaulted to the same value as `browser.dom.window.dump.enabled`, so chrome console.log will continue to go to stdout in local builds, automation, etc.<br>* devtools.console.stdout.content enables the stdout logging in console API when used in content contexts. It is false by default everywhere, so this feature will only be enabled with a manual override.<br></div></div><br><div>Brian<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 13, 2018 at 10:01 AM Brian Grinstead <<a href="mailto:bgrinstead@mozilla.com">bgrinstead@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Aug 13, 2018, at 8:36 AM, Andreas Tolfsen <<a href="mailto:ato@sny.no" target="_blank">ato@sny.no</a>> wrote:<br>
> <br>
> Hi, sorry for chiming in late.<br>
> <br>
> dump() is used extensively for logging through Log.jsm, and that<br>
> again is used in a lot of our test automation.<br>
<br>
`dump` behavior won’t change regardless of any changes here.<br>
<br>
> Also sprach Brian Grinstead:<br>
> <br>
>> Based on the discussion here and on the bug, I do think there’s<br>
>> value in being able to separately control chrome and content logs<br>
>> going to stdout. I’m leaning towards either:<br>
>> <br>
>> 1) Keep the current behavior for chrome callers and then add a<br>
>> second pref (false by default everywhere) to allow content logs to<br>
>> go out to stdout.<br>
> <br>
> Sorry, maybe this is a stupid question, but what exactly is a “chrome<br>
> caller” and how is it differentiated from a JSM using dump()?<br>
<br>
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.<br>
<br>
>> 2) Stop overloading `browser.dom.window.dump.enabled`, and instead<br>
>> add two new prefs like `devtools.console.stdout.chrome` and<br>
>> `devtools.console.stdout.content`. The chrome variation would be<br>
>> true by default in local builds and automation, I guess, and the<br>
>> content variation would be false by default everywhere.<br>
> <br>
> Being able to differentiate between web content uses of window.dump()<br>
> and those originating from privileged JS seems reasonable, but why<br>
> devtools.console.*?  Is dump() specific to devtools?<br>
<br>
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.<br>
<br>
Brian<br>
<br>
</blockquote></div>