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

Matthew N. MattN at mozilla.com
Thu Dec 21 08:44:19 UTC 2017


On Mon, Dec 18, 2017 at 4:13 PM, Brian Grinstead <bgrinstead at mozilla.com>
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 https://searchfox.org/mozilla-
> central/search?q=maxLogLevel&redirect=true. 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. https://searchfox.org/mozilla-
> central/source/browser/components/customizableui/CustomizableUI.jsm#167).
> For this case I believe we could replicate the log_level stuff from
> console.jsm (https://searchfox.org/mozilla-central/source/
> toolkit/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 / https://searchfox.org/mozilla-
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20171221/75d86185/attachment.html>


More information about the firefox-dev mailing list