296423 - Error panel should show file/line# reference

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[David A. Cobb]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+

An error message such as the one shown in the attachment is triggered by some
error in an extension chrome file.  However, I have many extensions and it is
not trivial to locate the bad one so it can be disabled.

The error panel should show the file 
(e.g. chrome://content/bad-extension/.../contents.rdf) and line# within the file.
The error description should also be within the visible area of the panel.


Reproducible: Always

Steps to Reproduce:
1. Install an extension that triggers some error during Application start-up.
2.
3.

Actual Results:  
See attachment.

Expected Results:  
Error panel should identify file and line#, and the error message should be visible.

Comment 1

[David A. Cobb]

Attachment: Screenshot showing pretty useless error panel.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This is a duplicate.  Please find the original and mark this duplicate.

Comment 3

[Tony Mechelynck [:tonymec]]

Boris: Now that bug 335755 has been FIXED, supposedly suppressing the gray bar altogether (at least on Trunk), I suppose this bug (to make the gray bar give _more_ info) is WONTFIX ?

Comment 4

[Boris Zbarsky [:bzbarsky]]

No idea...  The module owner is the right person to ask.

Comment 5

[Tony Mechelynck [:tonymec]]

In reply to comment #3 and comment #4:
According to http://www.mozilla.org/owners.html , "XP Toolkit" has no owner of record, but it has peers (including you, Boris): OK guys, do you think the fact that bug 335755 has been FIXED means that this bug is WONTFIX?

Comment 6

[Boris Zbarsky [:bzbarsky]]

I should probably be removed from that peer list.  I'll see if I can get that to happen.

Comment 7

[Wayne Mery (:wsmwk)]

robert - wontfix or WFM via error console?

Comment 8

[Robert Strong (they/them - no direct email)]

I'm not an XPToolkit peer but I think this should be wontfix

Comment 9

[David A. Cobb]

I don't mean to be a smarta**, but is that "Won't Fix" because some star doesn't want to, or because nobody is working this module at all?
Even if the error I showed is corrected by bug# 335755, this bug is about providing adequate error reporting on /any/ script error.

After four years, I have no idea whether this is still a problem.  I would need to create a bad script, and then know where to put it.  Nah!

I doubt much resources are being spent on this.  Can't it just be left alone?

Comment 10

[Wayne Mery (:wsmwk)]

I raised the question in hopes of getting this out of limbo unconfirmed.  i.e confirm if still valid and relevant (or find the dupe), else wontfix or ... - to keep it open because "no one" knows or cares isn't terribly smart.

rs, why are you thinking wontfix?  do these types of errors have line# in error console, or is this obsolete via some other reasoning?

Comment 11

[Robert Strong (they/them - no direct email)]

iirc we no longer display these errors in chrome as originally reported. It could possibly be morphed after the changed / new behavior is evaluated and suggested improvements are made as it relates to that but I personally prefer a new bug describing these suggestion in that instance.

Comment 12

[David A. Cobb]

I have to go along with Robert (Comment #11).  If the display in the attachment is no longer representative of what we do, the bug is no longer valid.  If I see script errors in recent builds, I'll file a new one.