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 ->
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.
Steps to Reproduce:
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?
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).
There is no one such module.....
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...
Sounds like bloat, and will likely *cause* more bug-reports than it helps
figuring out.. I doubt it would be helpful at all really.
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.)
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.
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...
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.
*** Bug 229173 has been marked as a duplicate of this bug. ***
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.
Bug 229173 is not really a dup of this, and most of comment 11 has nothing to do
with this bug.
cc'ing Bryan to get some views on this.
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
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.
(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/
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.