616586 - Internal console logging API for use in JSMs and Components

Status: RESOLVED WORKSFORME

(DevTools :: Console, defect, P3)

Description

[David Dahl :ddahl]

We need a more fine-grained, easy to use logging API for internal APIs in components and JSMs.

I sometimes would like to report an message to the nsIConsoleService that is not an error - maybe info or warning...

Something like:

Services.logger.warn("your fizzle is slightly bizabbled");
Services.logger.info("All is well, take a nap!");
Services.logger.error("x should be 5, not 7!! Jeez!!");
Services.logger.log("this message is neutral, deal with it");

I find myself too lazy to do all of the manual work of creating an nsIScriptError and calling Services.console.logMessage(aScriptError)

It would also be nice if this wrapper figured out the line and col numbers for you.

Comment 1

[Marco Bonardo [:mak]]

We could even provide a way to log to a file in profile folder. This kind of logging could be enabled for nightlies and could help debugging issues if we'd start using it. We could keep logs for the last X days. we can clearly manage writes to the file in a separate thread to avoid creating issues to nightly testers. It could also be enabled through a pref (Settable from about:support), so that support can ask user to enable logging, and get a log of what happened when a certain issue was reproduced.

Comment 2

[David Dahl :ddahl]

we should look at the nice implementation labs has: http://mxr.mozilla.org/services-central/source/fx-sync/services/sync/modules/log4moz.js

Comment 3

[David Dahl :ddahl]

Attachment: WIP - bare minimum logger

Comment 4

[David Dahl :ddahl]

also, noticed this bug 506121 - we should take all of the perf issues into consideration

Comment 5

[David Dahl :ddahl]

Attachment: 0.2 WIP bare minimum - untested:)

fixed some missing returns

Comment 6

[Marco Bonardo [:mak]]

Comment on attachment 495210 [details] [diff] [review]
0.2 WIP bare minimum - untested:)

globally it looks clean and simple to use.
I'd use a fake enum for levels, a-la
const LEVEL = {LOG: 0, INFO: 1, ...} and then using LEVEL.LOG
I'm not sure if there is a real need to differentiate between log and info output. Even if looks like log is something that could be toggled for debugging (thus it would need a way to toggle these messages), while info is something that is globally useful to output.
Instead of making this a new instance for each lazygetter (new LoggingAPI()) you could directly create a global object in the jsm and export it.

Comment 7

[David Dahl :ddahl]

(In reply to comment #6)
> Comment on attachment 495210 [details] [diff] [review]
> 0.2 WIP bare minimum - untested:)
> 
> globally it looks clean and simple to use.
> I'd use a fake enum for levels, a-la
> const LEVEL = {LOG: 0, INFO: 1, ...} and then using LEVEL.LOG
> I'm not sure if there is a real need to differentiate between log and info
> output. Even if looks like log is something that could be toggled for debugging
> (thus it would need a way to toggle these messages), while info is something
> that is globally useful to output.
> Instead of making this a new instance for each lazygetter (new LoggingAPI())
> you could directly create a global object in the jsm and export it.

Thanks marco! Good ideas. I will make those changes ASAP.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/AddonLogging.jsm

Has a simple impl of a logging helper

Comment 9

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Also being the lazy type I like this.

Do we really want this activated outside of debug builds?

Comment 10

[David Dahl :ddahl]

(In reply to Michael Ratcliffe from comment #9)
> Also being the lazy type I like this.
> 
> Do we really want this activated outside of debug builds?

I think so. There are times when you will want to call into this from someone's zombie machine via the scratchpad, or if the problem only manifests itself in an opt build. 

And then again, maybe these are corner cases?

Comment 11

[Mihai Sucan [:msucan]]

David, can we mark this as wfm/fixed/wontfix?

We landed the browser console in bug 587757. We also have a Console.jsm in toolkit/devtools that provides an almost complete console API implementation. In bug 851231 we landed support for output to the browser console.

For practical purposes the aforementioned patches allow the desired functionality.

Comment 12

[David Dahl :ddahl]

Does Console.jsm allow you to output to stdout? My intention was that this console API could be used in extensions and firefox hacking to isolate debug logging to a single context.

Comment 13

[Mihai Sucan [:msucan]]

(In reply to David Dahl :ddahl from comment #12)
> Does Console.jsm allow you to output to stdout? My intention was that this
> console API could be used in extensions and firefox hacking to isolate debug
> logging to a single context.

Console.jsm outputs to stdout and to the browser console. It can be used by extensions and by firefox devs.

Comment 14

[Matthew N. [:MattN]]

We also have Log.jsm to output to stdout via the DumpAppender. I really don't think we need yet another way to do logging in Firefox.