Last Comment Bug 125181 - Add pref to filter chrome:// errors in JS Console
: Add pref to filter chrome:// errors in JS Console
Status: VERIFIED FIXED
:
Product: Core Graveyard
Classification: Graveyard
Component: Error Console (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla1.0
Assigned To: Blake Ross
: John Morrison
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-13 00:49 PST by Bob Clary [:bc:]
Modified: 2010-05-04 05:24 PDT (History)
6 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch (4.71 KB, patch)
2002-02-24 14:21 PST, Blake Ross
bugs: review+
hewitt: superreview+
Details | Diff | Review
patch to fix spelling (15.00 KB, patch)
2002-02-27 05:50 PST, Alexey Chernyak
no flags Details | Diff | Review

Description Bob Clary [:bc:] 2002-02-13 00:49:35 PST
Internal JavaScript errors are reported to the JS Console using urls of the form
chrome://xxx, e.g.

Error: redeclaration of const hide
Source File: chrome://wallet/content/walletOverlay.js
Line: 1

These errors can be filtered in the JS Console based upon the chrome:// protocol.

These errors are useful for Mozilla developers to find and correct JavaScript
errors however they are not useful for Web Developers who are not concerned with
the internals of Mozilla.

These internal errors in the JS console are an embarrassment when attempting to
teach Web Developers how to use the JS Console to debug their JavaScript.

Of course the best solution would be to not have internal JS errors at all, but
that is not likely.

There would not necessarily need to be a UI for this pref.
Comment 1 John Morrison 2002-02-13 01:40:39 PST
I agree. We should do this.
Comment 2 Blake Ross 2002-02-13 12:12:07 PST
I would prefer to see us not do any work at all to report our errors if it's a
release build, rather than filtering out at the last possible moment.  But I
wonder if this info is useful for tech support, in which case having a way to
turn them on would be useful.
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-02-13 17:18:36 PST
These errors are incredibly helpful in nightlys if nothing else....  Having a
way for bug reporters to be able to provide that information would be good.
Comment 4 Blake Ross 2002-02-13 17:20:28 PST
Oh, definitely. We should probably have them on in milestones, too.  We should
provide an easy way for distributors to turn them off, though.
Comment 5 Cesar Eduardo Barros 2002-02-20 17:03:51 PST
Hiding the bugs under the carpet won't make them go away. I would find it more
embarrassing to hide them than to have them to begin with.

Oh yeah, and not being able to hide them is an extra incentive to fix ;-)
Comment 6 Bob Clary [:bc:] 2002-02-20 17:21:21 PST
What is embarrassing is trying to teach someone to use the JavaScript Console to
determine why their web page is not being displayed properly and have to teach
them to ignore the multitude of internal errors to find the relevant errors for
their web page. 

This is not intended to sweep anything under the rug, but is intended to make
supporting commercial releases of the browser easier.  

Of course these bugs should be fixed, and I heartily invite any and all to do
just that. But I get enough denigrating comments from users without having to
deal with this cruft that no one else seems to care about. 

I *need* a simple and clear mechanism to communicate errors in JavaScript to end
users and web developers who do not want to debug Mozilla.
Comment 7 Johnny Stenback (:jst, jst@mozilla.com) 2002-02-20 17:33:14 PST
I couldn't agree more with Bob.
Comment 8 Peter Trudelle 2002-02-20 18:36:02 PST
nsbeta1+ per Nav triage team.  
Comment 9 Peter Trudelle 2002-02-21 11:58:31 PST
Mass move of nsbeta1+ bugs that didn't have a valid MachV milestone to mozilla1.0.
Comment 10 Blake Ross 2002-02-24 12:31:07 PST
-> me
Comment 11 Blake Ross 2002-02-24 14:21:31 PST
Created attachment 71244 [details] [diff] [review]
patch
Comment 12 Joe Hewitt (gone) 2002-02-25 14:33:33 PST
Comment on attachment 71244 [details] [diff] [review]
patch

sr=hewitt
Comment 13 Ben Goodger (use ben at mozilla dot org for email) 2002-02-25 17:04:55 PST
Comment on attachment 71244 [details] [diff] [review]
patch

r=ben@netscape.com with the 'from chrome' (or similar) text change we discussed
on IRC.
Comment 14 Asa Dotzler [:asa] 2002-02-25 18:38:11 PST
a=asa (on behalf of drivers) for checkin to 0.9.9
Comment 15 Blake Ross 2002-02-26 16:48:47 PST
Fixed.
Comment 16 Henrik Gemal 2002-02-27 03:22:49 PST
small bug. JavaScript is not spelled "Javascript". It "JavaScript". With 
capital S
Comment 17 Alexey Chernyak 2002-02-27 05:50:40 PST
Created attachment 71656 [details] [diff] [review]
patch to fix spelling

The patch does 3 things:

1. Fixes "JavaScript" spelling in pref-debug.dtd
Tested by visually observing debug pane.

2. Renames debugStrictJavascript.label and debugConsoleJavascript.label to
debugStrictJavaScript.label and debugConsoleJavaScript.label inside
pref-debug.dtd and pref-debug.xul
Tested by visually observing debug pane as well as searching LXR for any files
that refer to debugStrictJavascript.label

3. Cleans out 434 trailing whitespaces inside pref-debug.xul and
consoleBindings.xml
Tested by reviewing the lines that patch modifies. As well as visually checking
every pref Category with the cleaned files. And checking JS Console during it.
(Yes I have no life)
Comment 18 Alexey Chernyak 2002-02-27 05:52:07 PST
reopening, review please
Comment 19 Blake Ross 2002-02-27 11:35:55 PST
Please file a new bug for nits...thanks.  The capitalized S does not need to be
fixed. This is debug UI!!
Comment 20 John Morrison 2002-05-20 23:10:34 PDT
verified.

Note You need to log in before you can comment on or make changes to this bug.