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

[Brian Grinstead]

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 .
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).

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?

Thanks,
Brian

[Matthew N.]

On Mon, Dec 18, 2017 at 4:13 PM, Brian Grinstead <bgrin...@mozilla.com>
wrote:

​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)

[Thom Chiovoloni]

FWIW, Log.jsm just got better support for using a preference for a log
level in https://bugzilla.mozilla.org/show_bug.cgi?id=1425987. 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.
https://searchfox.org/mozilla-central/source/services/common/logmanager.js
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
https://bugzilla.mozilla.org/show_bug.cgi?id=1072687 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 (
https://bugzilla.mozilla.org/show_bug.cgi?id=1350614, 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
https://searchfox.org/mozilla-central/source/toolkit/modules/Log.jsm#559-571
show up when the log is set to be particularly verbose).

- Thom

> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>