735896 - Incomplete implementation of bug 122213 (Console message timestamp)

Status: RESOLVED WONTFIX

(Toolkit Graveyard :: Error Console, enhancement)

Description

[David E. Ross]

Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 SeaMonkey/2.8

Bug #122213 provides a time-date stamp on entries in the Error Console.  This was supposedly implemented with Gecko 11 in SeaMonkey 2.8 and Thunderbird 11.0.  With SeaMonkey 2.8, however, Messages in the Error Console do not show time-date stamps.  These appear only for Errors and Warnings.  

In Thunderbird 11.0, I do see time-date stamps for Messages.  Unless the Error Console code in Thunderbird forked from Toolkit/Error Console, this indicates a problem in how the capability was implemented in SeaMonkey.

Comment 1

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows NT 5.0; rv:13.0a1) Gecko/20120201 Firefox/13.0a1] (nightly, 2012-02-01-03-11-46-mozilla-central)
[Mozilla/5.0 (Windows NT 5.0; rv:13.0a1) Gecko/20120201 Firefox/13.0a1 SeaMonkey/2.10a1] (nightly, 2012-02-01-00-30-09-comm-central-trunk)

Message example:
{
tbpl.mozilla.org : server does not support RFC 5746, see CVE-2009-3555
}

Neither FF nor SM seem to show a timestamp for messages.
Bug 122213 code seems 100% shared.

Could you attach a Firefox + Thunderbird screenshot(s)?
And maybe point to TB Console code?

Comment 2

[:aceman]

I thought info Messages intentionally do not have timestamps so I didn't touch that. It would probably need decision and changes on the Firefox/toolkit side to add them.

Comment 3

[Philip Chee]

This is totally shared code. Non-error console messages don't have timestamps by design (or rather nobody had requested/needed it before)

Comment 4

[David E. Ross]

Attachment: Error Console -- Errors

Error shows time-date stamp.

Comment 5

[David E. Ross]

Attachment: Error Console -- Warnings

Warnings show date-time stamps.

Comment 6

[David E. Ross]

Attachment: Error Console -- Messages

Messages do not show date-time stamp.  

If bug #474864 is implemented to allow selective deletions of entries, users will likely want to delete old entries and keep recent entries.  This will require identifying which entries are "old".  Implementing date-time stamps for Messages would enhance the usefulness of that RFE.  

What is necessary to provide meaningful data when an end-user is requested to communicate the relevant Error Console entries for an asserted problem?  Is it significant to a developer whether an entry is a Message, Warning, or Error?  If so, a date-time stamp must be contained in the entry, including Messages.

Comment 7

[:aceman]

I think you wanted to show us a screenshot from Thunderbird 11 where Messages do have timestamps. Can you attach that?

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to Philip Chee from comment #3)
> Non-error console messages don't have timestamps by design
> (or rather nobody had requested/needed it before)

Not entirely true: see bug 122213 comment 18...
(I didn't (re-)read all that bug...)

Comment 9

[David E. Ross]

Attachment: Error Console from Thunderbird -- Messages

Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0

Comment 10

[:aceman]

That does not look like real timestamps. The author of those messages manually included the time into the text of the message.

Comment 11

[Serge Gautherie (:sgautherie)]

David, please provide steps to reproduce.

As far as we can tell, your screenshots are unrelated to one another and none confirms (by itself) what you wrote in comment 0.

Comment 12

[David E. Ross]

I happened to install Thunderbird 11.0 before SeaMonkey 2.8.  Thus, I tested the fix for bug #122213 first.  Knowing that code in Thunderbird is sometimes forked from the basic Mozilla core, however, I then tested in SeaMonkey.  

I am not sure what is going on.  The Error Console is cleared whenever I terminate the application, Thunderbird or SeaMonkey.  Merely launching Thunderbird causes 34 Messages, 3 Warnings, and 1 Error to be inserted into the Error Console.  The Messages and Warnings all have the same date-time stamp; the Error has a date-time stamp 1 second later.  

In any case, please reread the last paragraph of my comment #6 in this bug report.  I suspect that Messages might indeed be relevant when diagnosing problems.

Comment 13

[David E. Ross]

Because of the large number of Messages, I captured screen shots of each Error Console entry-type separately.  I cropped the screen shots of Messages and Warnings to reduce the sizes of the JPEG files; I merely wanted to show some examples.  There was only one Error entry; I cropped that screen shot to eliminate the empty area of the Error Console window.  

I did not attempt to contrive any entries in the Error Console.  To view Error Console entries, I went to the SeaMonkey menu bar and selected [Tools > Web Development > Error Console].  I then selected the Errors, Warnings, and Messages buttons on the Error Console window tool bar.

Comment 14

[Serge Gautherie (:sgautherie)]

(In reply to David E. Ross from comment #12)
> please reread the last paragraph of my comment #6 in this bug report.

You miss the point: your comment 0 and comment 6 are very different.
The former complains about a (SeaMonkey) misbehavior, the latter is an (Toolkit) enhancement request.
We are asking you to either provide missing details about comment 0 or (to confirm you want) to (fully) morph this bug to be comment 6.

Comment 15

[David E. Ross]

Seeing date-time stamps for Messages in Thunderbird and not for Messages in SeaMonkey indicates to me that there is a bug somewhere.  If what I see in Thunderbird is an artifact created by some developer, I think we need confirmation from the Thunderbird team.  In the meantime, my original Description stands.  

My comment #6 was in response to the assertion in comment #3 that date-time stamps were intentionally omitted for Messages, which seems contradicted by what I see with Thunderbird.  

Bug #713398 addresses making the formats of the three types of Error Console entries consistent so that they can be analyzed by software; this would require a date-time stamp on Messages, which now makes me believe this bug is a duplicate of bug #713398.

Comment 16

[Serge Gautherie (:sgautherie)]

(In reply to David E. Ross from comment #15)

> Seeing date-time stamps for Messages in Thunderbird and not for Messages in
> SeaMonkey indicates to me that there is a bug somewhere.

This is irrelevant: you never compared the "same" message in different applications.

> In the meantime, my original Description stands.  

R.Incomplete (wrt SeaMonkey) -> R.Invalid (as too confused now)

> *** This bug has been marked as a duplicate of bug 713398 ***

This is just crazy: in addition to mixing two issues in this bug, you now duplicate it to another bug which is about a totally different issue (from a developer standpoint).

Comment 17

[:aceman]

I think bug 713398 is not that much out of scope, it wants to add the "message:" prefix to Messages because the other types already have prefixes. Yes, it then morphed into some CSV format request.

But in similar way timestamp could be added to Messages (what this bug reduces to) to make it match the other types. I think you agree with this change (bug 122213 comment 18) so just clear up which bug is which feature (or merge them into 713398, which would fit as it has a universal summary). And I can then look at it.

Comment 18

[David E. Ross]

Bug #713398, by its Summary, requests that Errors, Warnings, and Messages have a single, consistent format.  By that, I would include the entry-type, a date-time stamp, and the result of copy-paste.  This is all implied by the last paragraph of the Description.  

My later comments about the specific format (e.g., about being able to create a spread sheet) relate more to why a consistent format is needed and how it might be used.  I was not trying to indicate how to implement the change.  

In any case, this bug is closed.

Comment 19

[David E. Ross]

Is it now proposed to reopen this bug report?

Comment 20

[:aceman]

Not yet, I just wanted to somehow mark a link between the bugs.
Depends on what Serge and Philip think.

Comment 21

[Philip Chee]

I'm not a toolkit peer. However Neil is so perhaps we should ask his opinion.

Comment 22

[[e-mail]]

Well, although the Error Console itself is toolkit, it relies on the Console Service, which is core XPCOM code, and adding message timestamps would need an API change on nsIConsoleMessage and nsIScriptError, so I asked Boris Zbarsky on IRC and he seemed to think that it was a reasonable change to make.

Comment 23

[:aceman]

Cool. And which bug do we use for it?

Comment 24

[Tony Mechelynck [:tonymec]]

IIUC, this bug should not be INVALID, but from the above it isn't obvious to me whether it should be fixed on its own, or duped (and to what). Reopening.

Comment 25

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #23)
> Cool. And which bug do we use for it?

I didn't find anything relevant in xpcom component mentioning timestamp, so perhaps someone will need to file one

Comment 26

[Brian Grinstead [:bgrins]]

The Error Console has been removed in favor of the Browser Console (see Bug 1278368), and the component is going to be removed.  If this bug is also relevant in the Browser Console, please reopen and move this into Firefox -> Developer Tools: Console.

Comment 27

[Zack Weinberg (:zwol)]

I am mass-reopening and re-componenting every single one of the Toolkit:Error Console bugs that appear to have been closed without anyone even *glancing* at whether they were relevant to the Browser Console.

If you want to close a whole bunch of old bugs -- FOR ANY REASON -- it is YOUR RESPONSIBILITY to check EVERY SINGLE ONE OF THEM and make sure they are no longer valid.  Do not push that work onto the bug reporters.

(It's okay to close bugs that haven't been touched in years when they don't have enough information for you to figure out whether the problem is still relevant to the current software - the reporter probably isn't coming back to clarify.  But that is the ONLY situation where it is okay.)

(I'm going to have to do this in two steps because of the way the "change several bugs at once" form works.  Apologies for the extra bugspam.)

Comment 28

[Brian Grinstead [:bgrins]]

The Error Console feature was removed entirely from the tree in Bug 1278368 and the bugzilla component is now being removed. We’ve migrated bugs that seem to also affect the Browser Console into the devtools component, please move this over if it was missed.