Open Bug 435025 Opened 16 years ago Updated 2 years ago

[meta] Make Mozilla Error Messages Better

Categories

(DevTools :: Console, task)

task

Tracking

(Not tracked)

People

(Reporter: johnjbarton, Unassigned)

References

(Depends on 13 open bugs)

Details

(Keywords: meta, Whiteboard: [firebug-p2])

This is tracking bug report to consolidate error message information.

Please put bugzilla reports related to better error messages on the 'depends on' list. 

Please elaborate on specific error messages in their own bug report.

See also http://wiki.mozilla.org/Gecko:ErrorMessages
Um, John, why WindowsXP only? Don't you care about error messages on linux and OSX?
OS: Windows XP → All
Hardware: PC → All
Keywords: meta
Philip I think someone already fixed this oversight, thanks, John
No longer depends on: 286661
Depends on: 435896
Here is a poster child for errors that puzzle a developer.

I get an exception with these properties:

[QueryInterface]=function QueryInterface() {
    [native code]
}
[message]=Component is not available
[result]=2147746065
[name]=NS_ERROR_NOT_AVAILABLE
[filename]=file:///C:/bartonjj/projects/fireclipse/trunk/FireclipseExtensions/firebug/branches/firebug1.2/components/firebug-service.js
[lineNumber]=1603
[columnNumber]=0
[location]=JS frame :: file:///C:/bartonjj/projects/fireclipse/trunk/FireclipseExtensions/firebug/branches/firebug1.2/components/firebug-service.js :: anonymous :: line 1603
[inner]=null
[data]=null
[initialize]=function initialize() {
    [native code]
}

1603 is the call to ddd:

var url = sourceFile.href;
var urlBreakpoints = breakpoints[url];
if (fbs.DBG_FBS_BP)
  ddd("resetBreakpoints: breakpoints["+sourceFile.href+"]="+urlBreakpoints+"\n");

So I have already accessed sourceFile.href and breakpoints is just one of my objects.  So what could Component is not available really mean? (this code is in a component).
Depends on: 442489
Depends on: 443424
Depends on: 312448
Depends on: 445280
Depends on: 445355
Product: Firefox → Toolkit
Depends on: 228205
I found Bug 389002 and 228304 by search on
Security Error 1000

Clearly 228304 should have said 
"For security reasons, we don't allow setting the value of a file input." But "1000" is close enough?

In my case the  error is
Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "XPCSafeJSObjectWrapper.cpp Line: 445"]"
Depends on: 389002, 228304
Depends on: 465672
Progress:
445280 - was Firebug problem.
416508 - was 'resolved', but the test case on that report shows how pathetic the error messages are.
434522 - I got so sick of this one I delete them rather than show in Firebug. 
408512 - was fixed because it affected platform developers.

Setbacks:
465672 - jsd error processing looks broken
FYI: https://developer.mozilla.org/En/Exception_logging_in_JavaScript
"you can set the boolean preference 
dom.report_all_js_exceptions
If this preference is true, all exceptions from inner frames will be logged."
Here's another nice one:

Error: uncaught exception: 2147942487

No file or line info. In fact that's the entire message.
$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
obase=16
2147942487
80070057
^D
$ grep 057 ../../xpcom/*/nsError.h
#define NS_ERROR_ILLEGAL_VALUE             ((nsresult) 0x80070057L)

Still opaque as hell, but that's how you start to track down such bugs. Problem now is that many places return that nsresult. Which DOM or JSD or other XPCOM method was called that might have returned this code?

/be
Depends on: 477311
Depends on: 483672
Depends on: 486229
I totally agree on this front.
I was browsing Google Chrome's "inspector"
chrome-resource://inspector/inspector.html  Developer->Javascript Console

It gave me some excellent informational/warning messages as it parsed a page.

XML self-closing tag syntax used on <a>. The tag will not be closed. http://testserver/badlywrittenapp/somepage (line 26)
<a> misnested or not properly closed.  Cloning <a> in order to preserve the styles applied by it. http://testserver/badlywrittenapp/somepage (line 36)

I have no idea at what level that chatty text comes from (the parser or some reasonable error message by the parser that is interpreted by the tool) but from my perspective it is awesome for figuring out how a quirky page ended up running the way it did.
Depends on: 495176
Spent a couple of more days rediscovering comment 9.
Whiteboard: [firebug-p2]
Bug 515051 appears to be caused by xpconnect discarding errors from JS components.
jsd.onError() gets called (correct), but no error is posted to the consoleService(bug)
Bug 499568 jsd.onError() gets called but no Error Console entry is created.
jsd.OnError() gets called (bug), but no error is posted to the ConsoleService (correct).
Depends on: 515051, 499568
Depends on: jserror
Depends on: 862529
Depends on: 261337
Depends on: 862153
Depends on: 928250
Depends on: 930397
Depends on: 931720
(In reply to John J. Barton from comment #0)
> This is tracking bug report to consolidate error message information.
> 
> Please put bugzilla reports related to better error messages on the 'depends
> on' list. 
> 
> Please elaborate on specific error messages in their own bug report.
> 
> See also http://wiki.mozilla.org/Gecko:ErrorMessages

Is this only for DOM scripting error messages?
If so, is there a meta entry for TB messages?

TIA
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 → ---
Status: REOPENED → NEW
Summary: Make Mozilla Error Messages Better → [meta] Make Mozilla Error Messages Better
Depends on: 1442551
Product: Firefox → DevTools
Type: defect → task
Depends on: 1687683
Depends on: 1740420
No longer depends on: 1740420
No longer depends on: 1740420
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.