<div dir="ltr"><div>Note the console message service also has '<code id="gmail-line-154"><span class="gmail-syn_string">consoleservice.logcat</span></code>' [1] for android that dumps to logcat at the appropriate log levels when enabled (I believe it's enabled by default for nightly), we had a similar implementation for b2g as well [2] that covered the mapping of console functions to log levels. Our gecko logging code prefixes log levels [3] and supports logging only certain levels [4] to keep verbosity down, this might be something worth reusing.</div><div><br></div><div>In general, please keep this pref opt-in and disabled by default in automation to avoid excessive log spam.<br></div><div><br></div><div>-e</div><div><br></div><div>[1] <a href="https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfbaf6e2d52f3466d2b27ad1de/xpcom/base/nsConsoleService.cpp#153-161">https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfbaf6e2d52f3466d2b27ad1de/xpcom/base/nsConsoleService.cpp#153-161</a><br></div><div>[2] <a href="https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=1060171">https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=1060171</a><br></div><div>[3] <a href="https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfbaf6e2d52f3466d2b27ad1de/xpcom/base/Logging.cpp#88-105">https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfbaf6e2d52f3466d2b27ad1de/xpcom/base/Logging.cpp#88-105</a></div><div>[4] <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Gecko_Logging#Logging_interface">https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Gecko_Logging#Logging_interface</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 3, 2018 at 7:40 AM, Brian Grinstead <span dir="ltr"><<a href="mailto:bgrinstead@mozilla.com" target="_blank">bgrinstead@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Brian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Aug 2, 2018, at 7:25 PM, Mike Hommey <<a href="mailto:mh@glandium.org">mh@glandium.org</a>> wrote:<br>
> <br>
>> On Fri, Aug 03, 2018 at 12:15:50PM +1000, Mark Hammond wrote:<br>
>>> On 3/08/2018 5:16 am, Brian Grinstead wrote:<br>
>>> 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).<br>
>>> <br>
>>> Interestingly, a page can already get text out to stdout if browser.dom.window.dump.<wbr>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.<br>
>>> <br>
>>> 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.<wbr>enabled pref? Should we have a second pref controlling itf? Something else?<br>
>> <br>
>> This is tricky. I use dump() more than I'd care to admit - it works well in<br>
>> content code because you almost never see dump() used in real sites (does<br>
>> Chrome even support it?), so there's not a huge amount of "spam" in the<br>
>> terminal. Having dump() output from *both* chrome and content can be very<br>
>> helpful.<br>
>> <br>
>> If we also wrote console.log() from content to the terminal, I fear we would<br>
>> then end up in a situation where content spams the terminal, with the only<br>
>> mitigation being to flip browser.dom.window.dump.<wbr>enabled to false - but that<br>
>> means we also lose dump() output, throwing the baby out with the bathwater.<br>
>> <br>
>> So my vote would be:<br>
>> <br>
>> * Leave dump alone - it's basically a firefox-specific easter-egg and no one<br>
>> seems to mind that content *could* spam the terminal because it almost never<br>
>> does. (I know this wasn't proposed, but it's worth clarifying imo)<br>
>> <br>
>> * A new pref that would allow content console.* output to be written to this<br>
>> terminal. I'd be fine with this defaulting to true wherever<br>
>> browser.dom.window.dump.<wbr>enabled does.<br>
>> <br>
>> Having "dump" in the name of this pref wouldn't be a good option, because<br>
>> IMO, it should *not* affect the behaviour of dump()<br>
> <br>
> There's javascript.options.<wbr>showInConsole, too, but I'm not sure it does<br>
> anything these days, despite being defined in all.js, firefox.js and<br>
> other places, it seems it was made a no-op by the error console removal<br>
> in bug 1278368.<br>
> <br>
> Mike<br>
> ______________________________<wbr>_________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
</div></div></blockquote></div><br></div>