Moving towards retiring Console.jsm - feedback wanted on the maxLogLevel feature

Thom Chiovoloni tchiovoloni at
Thu Dec 21 15:47:18 UTC 2017

FWIW, Log.jsm just got better support for using a preference for a log
level in We use
Log.jsm a lot in Sync, and collecting logs from bug reporters is a
common/important use case for us, but we have to do a decent amount of
legwork in order to set this up (e.g.
and about:sync-log).

We've had better luck here than asking contributors to give us logs from
the console, though. At least, you're much less likely for them to send a
bunch of screenshots of the log text. Note that if is fixed, just
copying/pasting data from the console wouldn't even have all the
information, since it wouldn't have fully expanded objects... (unless
there's another way to get log text out of the console?)

That said, I think Log.jsm is kind of overengineered (I guess the ship has
probably sailed on this...). It's also not particularly fast, and will
sometimes show up on performance profiles (, although it's not
clear how much of that is due to sync spinning event loops and making the
log hard to read (which it only does in observers now, and won't do at all
soon, bug 633062); personally, I've also seen
show up when the log is set to be particularly verbose).

- Thom

On Thu, Dec 21, 2017 at 3:44 AM, Matthew N. <MattN at> wrote:

> On Mon, Dec 18, 2017 at 4:13 PM, Brian Grinstead <bgrinstead at>
> wrote:
>> Baku has been working on a set of patches that will expose the WebIDL
>> console to JSM files. This will have the benefit of a console global being
>> available directly from JSM files. I for one am excited to not accidentally
>> throw an exception calling console.log after forgetting to copy and paste
>> `let { console } = Cu.import("resource://gre/modules/Console.jsm", {});`
>> into the top of a jsm file.
>> Bug 1425463 is on file to expose the console global in JSM files, and Bug
>> 1425574 is on file to fill the feature gap between them. Here are the main
>> dev-facing features that are currently missing from the WebIDL version:
>> 1. No way to construct console instances with custom options
>> 2. Doesn’t dump to stdout
>> 3. Doesn’t support the ‘prefix’ option to prepend text in front of all
>> messages
>> 4. Doesn’t support the ‘maxLogLevel’ and ‘maxLogLevelPref’ options
>> There are patches in Bug 1425574 to cover items 1-3, so I wanted to get
>> some feedback about (4). I do see this ‘maxLogLevel’ feature is referenced
>> quite a few times in the tree and so I wanted to get an idea of how often
>> the feature is actually used in development
>> It looks like there are a couple of patterns:
>> 1) A runtime pref check in a ‘log’ function getter like `maxLogLevel:
>> debug ? "all" : “log”` (i.e.
>> central/source/browser/components/customizableui/CustomizableUI.jsm#167).
>> For this case I believe we could replicate the log_level stuff from
>> console.jsm (
>> modules/Console.jsm#288) easily enough in the getter .
> ​A few of these cases would have used maxLogLevelPref if they were written
> today but were converted to use​ the ternary operator to preserve backwards
> compatibility for profiles that already had a boolean pref set with custom
> dump() logging.
>> 2) maxLogLevelPref being set as a way to control which logs are seen by a
>> pref which is presumably something you change in a dev profile but the
>> default pref value prevents any logs from showing up (i.e.
>> dom.push.loglevel /
>> central/source/dom/push/Push.js#19).
> ​Or the pref defaults to Warn or Error so Debug logs don't show up​ by
> default but can be toggled at runtime via the pref.
> My suspicion is that (2) *is* actually used by firefox devs and is
>> something that we’ll need to continue supporting somehow (possibly in a
>> stripped down version of Console.jsm that you could import if you need to
>> use this feature). But I’d like to confirm that it is used before we do the
>> work to support it. Here are the files where maxLogLevelPref is referenced:
>> * browser/components/downloads/DownloadsCommon.jsm
>> * browser/components/migration/ESEDBReader.jsm
>> * browser/components/uitour/UITour.jsm
>> * browser/extensions/formautofill/FormAutofillUtils.jsm
>> * browser/extensions/formautofill/MasterPassword.jsm
>> * browser/extensions/pocket/content/AboutPocket.jsm
>> * browser/tools/mozscreenshots/mozscreenshots/extension/Screenshot.jsm
>> * dom/push/Push.js
>> * dom/push/PushDB.jsm
>> * dom/push/PushService.jsm
>> * dom/push/PushServiceAndroidGCM.jsm
>> * dom/push/PushServiceHttp2.jsm
>> * dom/push/PushServiceWebSocket.jsm
>> * toolkit/components/extensions/ExtensionUtils.jsm
>> * toolkit/components/payments/content/paymentDialogFrameScript.js
>> * toolkit/components/payments/paymentUIService.js
>> Could you please reply if you work with any of these files and take
>> advantage of this feature in local development?
> ​The point of the maxLogLevelPref feature is to be able to ​
>> ​flip a pref to toggle log levels at runtime. This isn't just used for
> local development, it's also used for collecting logs from bug reporters.
> Having a live pref allows for gathering logs in some cases which would be
> hard to reproduce after a restart (e.g. if env. vars were used instead) and
> flipping prefs is much easier for end users.​
> One of the main benefits of Console.jsm over Log.jsm is that it can log JS
> objects which can be inspected/expanded/referenced in the console and I
> hope that is preserved with bug 1425574. I hope the log prefix will also
> continue to be formatted specially as it really helps in scanning logs.
> ​I regularly use this feature with the following files: ​
> * browser/components/uitour/UITour.jsm
> * browser/extensions/formautofill/FormAutofillUtils.jsm
> * browser/extensions/formautofill/MasterPassword.jsm
> * browser/tools/mozscreenshots/mozscreenshots/extension/Screenshot.jsm
> * toolkit/components/payments/content/paymentDialogFrameScript.js
> * toolkit/components/payments/paymentUIService.js
> I think the person who added the next most would be Kit with the Push ones.
> ​Thanks,
> Matthew
> P.S. I would be fine with replacing Console.jsm usage with Log.jsm if
> Log.jsm required much less boilerplate to observe a pref for the log level
> and supported rich logging of objects out of the box​ (bug 1072687)

> _______________________________________________
> firefox-dev mailing list
> firefox-dev at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list