Open Bug 713398 Opened 12 years ago Updated 2 years ago

Copy/Pasting messages should indicate the log level

Categories

(DevTools :: Console, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: david, Unassigned)

References

Details

Attachments

(1 file)

There are three types of Error Console entries:  Errors, Warnings, and Messages.  When copying an entry and pasting it into an ASCII editor, Errors and Warnings begin with the entry-type; but Messages have no entry-type.  

All three entry-types should have a single, consistent format that is easily parsed if Error Console entries are to be analyzed by software.  Omitting the entry-type for Messages violates that principle.  

Reference bug #711723.
You mean the format of the message when it is copied from the Console to the clipboard, using the Copy from context menu? It looks like this:

*Message:*
No chrome package registered for chrome://treestyletab-platform/skin/base.css

*Warning:*
Warning: Ignoring obsolete chrome registration modifier 'xpcnativewrappers=no'.
Source file: /homenew/inet/.mozilla/firefox/wjmliv0o.default/extensions/inspector@mozilla.org.xpi:chrome.manifest
Line: 17

*Error:*
Error: revToRel is not defined
Source file: chrome://linkwidget/content/code.js
Line: 479
Assignee: nobody → acelists
Attached file suggested format
Neither asterisks nor the redundancies shown for Errors and Warnings (as shown in comment #1) are necessary.  What is necessary (I hope I do not need another bug report for this) is that there be separation characters not otherwise used in the entry, to aid in parsing.  

The attachment is an ASCII file with a mock-up of how pasted entries might appear.  It should be viewed without any line-wraps.  I have added a date-time stamp.  I chose a bar (|) as the separation character because I do not think it will otherwise appear in a message.  The result is three fields: entry-type, date-time stamp, entry text.  I did not make a field for a URI or domain because these are part of the entry text and appear differently (e.g., whether the entry represents a server problem (domain) or a Web page problem (URI)).
Isn't linebreak (EOL) enough of a special character as a delimiter?

The format proposed in the attachment is a more radical change than I originally understood from your request. You want something like CSV. I am not sure that would pass.
It EOL were the separation character within an entry, what would separate multiple entries?  

As I recall, an EOL on a PC is a is CR/LF (which are coded as the bytes x0D and x0A respectively).  On a UNIX platform (and perhaps with Linux), however, an EOL is merely LF (x0A) without any CR.  I do not know what Mac platforms use.  Which EOL would be used?
> It EOL were the separation character within an entry, what would separate multiple
> entries?  

Console^2 uses some dashes on a line by themselves for this.
Going by bug 735896, to make the format consistent, also the timestamp needs to be added to Messages (as Errors and Warnings have).

Would there be acceptance of this in toolkit?
Blocks: 735896
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
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.)
Status: RESOLVED → REOPENED
Component: Error Console → Developer Tools: Console
Product: Toolkit → Firefox
Resolution: WONTFIX → ---
Version: 12 Branch → Trunk
Windows 7 Ultimate SP1
SeaMonkey/2.40
Thunderbird/45.1.1

In the most current end-user releases of SeaMonkey and Thunderbird, this is still a problem.  If the Browser Console is implemented in those two applications, this problem needs to be resolved.  Otherwise, software to process the errors, warnings, and information entries (or whatever they are called in Browser Console) cannot be readily developed.
Browser Console also separates messages with newlines, and the clipboard output could be just generally better.  Keeping this open in devtools component
Status: REOPENED → NEW
Priority: -- → P3
Yes, the copied output of the Browser console is a mess too.
Assignee: acelists → nobody
OS: Windows XP → All
Priority: P3 → --
Hardware: x86 → All
Actually when copying from the Browser console, there is no indication of the message severity. No Error/Warning/Message keyword.
Product: Firefox → DevTools
Priority: -- → P3
Summary: Need a Single, Consistent Entry Format for Errors, Warnings, and Messages → Copy/Pasting messages should indicate the log level
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: