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

Eric Rahm erahm at mozilla.com
Mon Aug 6 18:21:13 UTC 2018


Note the console message service also has 'consoleservice.logcat' [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.

In general, please keep this pref opt-in and disabled by default in
automation to avoid excessive log spam.

-e

[1]
https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfbaf6e2d52f3466d2b27ad1de/xpcom/base/nsConsoleService.cpp#153-161
[2] https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=1060171
[3]
https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfbaf6e2d52f3466d2b27ad1de/xpcom/base/Logging.cpp#88-105
[4]
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Gecko_Logging#Logging_interface

On Fri, Aug 3, 2018 at 7:40 AM, Brian Grinstead <bgrinstead at mozilla.com>
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 glandium.org> 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 mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20180806/7a5182fe/attachment.html>


More information about the firefox-dev mailing list