Last Comment Bug 193873 - Add Mozilla logging to UI.
: Add Mozilla logging to UI.
Status: NEW
:
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: x86 Windows XP
: -- enhancement with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks: 215129 229173
  Show dependency treegraph
 
Reported: 2003-02-18 09:06 PST by Jason Bassford
Modified: 2014-01-27 05:28 PST (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jason Bassford 2003-02-18 09:06:22 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030217

It would be useful if we had a UI way of turning logging on and off, rather than
having to manually set environment variables for that purpose.  I propose a
simple menu toggled menu item in the Debug menu with the settings of
"nspr_log_modules=all:5" and "nspr_log_file=%application_dir%\mozilla.log".

With this, it would be easy for somebody to tell a user to simply go to Debug ->
Enable Logging.

Further, I would suggest that it take effect only for the next Mozilla session
(the user would be prompted to restart Mozilla, and any session subsequent to
the logged session would automatically disable logging), and that when it
becomes active it overwrite any previous log.  This way there'd be no chance of
somebody turning it on and forgetting about it, causing runaway logfile sizes.

A related UI feature would be a "View Log" entry.

Reproducible: Always

Steps to Reproduce:
Comment 1 Boris Zbarsky [:bz] (TPAC) 2003-02-18 10:51:25 PST
> "nspr_log_modules=all:5"

Jason, have you ever actually tried this setting and tried to read the resulting
log?  ;)  I doubt such a log would be very useful or usable...  I know that it
would be totally unusable for me, as a developer.

Other than that little issue, NSPR can't depend on prefs, so we would need some
other way of doing this.... wtc, any ideas?
Comment 2 Jason Bassford 2003-02-18 10:59:11 PST
> "nspr_log_modules=all:5"

Hmm.  I was trying to get a setting that would always be useful - but if this is
overkill to the point of being unusable, maybe just "nsHTTP:5" then (or
whichever module is the one most commonly in need of debugging).
Comment 3 Boris Zbarsky [:bz] (TPAC) 2003-02-18 11:07:40 PST
There is no one such module.....
Comment 4 Jason Bassford 2003-02-18 11:16:45 PST
Then I suppose multiple modules could be selected that, together, would not be
as bad as "all" but still useful a significant portion of the time.

If that's not feasible, then logging options could be set via a Preferences ->
Debug -> Logging panel.  (Whatever it's set to there is what will be used by the
menu item Debug -> Enable Logging.)

Assuming that the general idea itself is workable...
Comment 5 R.K.Aa. 2003-02-18 11:29:24 PST
Sounds like bloat, and will likely *cause* more bug-reports than it helps
figuring out.. I doubt it would be helpful at all really.
Comment 6 Jason Bassford 2003-02-18 11:36:47 PST
I just thought if there were some simple way of introducing a toggle for logging
in the UI it would be benefical for the purpose of instructing users on how to
send somebody a log.  (Rather than relaying the far harder concept of opening a
command window, setting envirionment variables, and running Mozilla from there
rather than using the icon their used to.)  I know that other applications have
logging facilities built into their UI, and thought it could be handy here.

But I'm happy to forget about it if it would be more trouble than it's worth. 
(Still, I'll leave it up to the module owner (?) to WONTFIX it.)
Comment 7 Wan-Teh Chang 2003-02-18 13:18:27 PST
Unfortunately NSPR's logging functions are not designed
to be dynamically reconfigurable.  NSPR's logging facility
is configured only during NSPR initialization by reading
the environment variable NSPR_LOG_MODULES.
Comment 8 Boris Zbarsky [:bz] (TPAC) 2003-02-18 13:26:21 PST
Right.  But the idea is to require a restart for this to take effect anyway. 
The basic question is whether there's a reasonable way (that could be added by
slightly modifying Mozilla or NSPR or both) for Mozilla to persist this
information to the next restart, for NSPR to read during init.  I suspect the
answer is "no", but wanted to verify that...
Comment 9 Wan-Teh Chang 2003-02-19 21:34:57 PST
We may be able to add a new NSPR function, PR_SetLogModules,
that dynamically change the logging levels for the specified
log modules.  I will need to think through the thread safety
issues of this function.
Comment 10 Frank Wein [:mcsmurf] 2003-12-22 11:04:00 PST
*** Bug 229173 has been marked as a duplicate of this bug. ***
Comment 11 :aceman 2003-12-23 02:31:47 PST
I am waiting for this for a long time. OE has POP3/SMTP logging at least since
4.x. Usually Mozilla doesn't hide information from the user. Why does it do it
here? And don't add the pref into some Debug subtree in Preferences, which is
not available in stable releases. This should be a standard feature accessible
in the appropriate trees (e.g. Account settings in MailNews). Like OE does it. I
don't know why Mozilla hides such valuable data, which can help solve unexpected
situations on the mailserver. E.g. recently my SMTP server started to reject
some of my emails, because it said, there may be some viruses. Fortunately,
Mozilla popped up a dialog saying this. But what if Mozilla silently failed to
send the emails? There would be no way to find out what happened.

Logging is a standard feature in all serious applications. And seems to be
already there, we just have to show it to users and enable it somehow.
Comment 12 Boris Zbarsky [:bz] (TPAC) 2003-12-23 21:26:46 PST
Bug 229173 is not really a dup of this, and most of comment 11 has nothing to do
with this bug.
Comment 13 Gary Kwong [:gkw] [:nth10sd] 2008-04-01 14:27:32 PDT
cc'ing Bryan to get some views on this.
Comment 14 Wayne Mery (:wsmwk, NI for questions) 2008-06-16 08:15:38 PDT
xref Bug 237326 has draft patch – PR_NewLogModule is not threadsafe -- timeless writes "i have an xpcom component (service) which lets you twiddle arbitrary modules, we use it here and it works fairly well, but i need something landed in nspr (with known apis) before i can reasonably post the xpcom component."

xref Bug 386218 – allow debug/trace logging of mail events to directory
Comment 15 Vitus LM 2011-07-03 23:01:08 PDT
For my add-on TBTracer I wrote 3 little shell scripts, that set the necessary environment vars to enable logging (*nix, osx, win), and yes they do need a restart of TB (and re-login of the user in osx).
They work, but I do agree that setting that from within the prefs window as a checkbox would make it even easier. 
TBT does provide a log view UI.
Comment 16 Vitus LM 2011-07-03 23:02:02 PDT
(In reply to comment #15)
> For my add-on TBTracer I wrote 3 little shell scripts, that set the
> necessary environment vars to enable logging (*nix, osx, win), and yes they
> do need a restart of TB (and re-login of the user in osx).
> They work, but I do agree that setting that from within the prefs window as
> a checkbox would make it even easier. 
> TBT does provide a log view UI.

Oh, forgot, TBT can be found here: https://addons.mozilla.org/en-US/thunderbird/addon/tbtracer/
Comment 17 Joshua Cranmer [:jcranmer] 2012-03-04 16:26:00 PST
As an aside, I wrote an addon that dynamically enables/disables logs from the UI, without requiring restart: <https://addons.mozilla.org/en-US/thunderbird/addon/loghelper/>.

This addon uses some pretty gross hacks (<https://addons.mozilla.org/en-US/thunderbird/files/browse/141114/file/modules/logging.jsm#top> has most of the hacked-up ctypes code) to work, though.

Note You need to log in before you can comment on or make changes to this bug.