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:
> "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?
> "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).
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
Assignee: asa → general
QA Contact: asa → general
Assignee: general → nobody
Product: SeaMonkey → Core
QA Contact: general → general
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.
Fixed by bug 1303762 (and bug 1174972) - the UI for it is in about:networking, Logging tab
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1303762
Since this is in Core, will this hopefully also be available in Thunderbird?
You need to log in before you can comment on or make changes to this bug.