Last Comment Bug 275265 - add javascript&CSS/javascript/CSS radiobuttons to the Error Console
: add javascript&CSS/javascript/CSS radiobuttons to the Error Console
Status: RESOLVED WONTFIX
:
Product: Toolkit Graveyard
Classification: Graveyard
Component: Error Console (show other bugs)
: Trunk
: All All
-- enhancement with 37 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 319764 (view as bug list)
Depends on: 264162 312962
Blocks: 306223 490886
  Show dependency treegraph
 
Reported: 2004-12-19 05:56 PST by Peter van der Woude [:Peter6]
Modified: 2016-06-29 11:02 PDT (History)
36 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch (10.01 KB, patch)
2005-09-01 14:22 PDT, Martijn Wargers [:mwargers]
mconnor: review-
Details | Diff | Splinter Review
patch2 (9.38 KB, patch)
2005-11-20 12:28 PST, Martijn Wargers [:mwargers]
no flags Details | Diff | Splinter Review

Description User image Peter van der Woude [:Peter6] 2004-12-19 05:56:05 PST
Currently both javascript and CSS warnings/errors are displayed in the
Javascript console, creating a rather chaotic list.
It would be very usefull if these warnings/errors could be filtered so that you
can get what you want to see.

[All][Errors][Warnings][Messages][Clear] javascript+CSS[0]|javascript[ ]|CSS[ ]

Default left as javascript+CSS

This would greatly improve the usefullness of the console especially when you
look for CSS errors.

( Yes, I am aware bug 264162 was marked WONTFIX. )
Comment 1 User image Stipe Kotarac 2004-12-19 10:32:34 PST
I think it would be a nice change. I'll vote for this.
Comment 2 User image Ben Basson 2005-03-24 11:57:49 PST
A nice addition to this would be to isolate chrome errors too. It's a pain
trying to debug an extension when testing a website that has bad JavaScript AND
bad CSS. Maybe instead of radiobuttons, there should simply be checkboxes - one
for each.
Comment 3 User image Nickolay_Ponomarev 2005-08-11 04:11:20 PDT
See also bug 296664; as a workaround use the (wonderful) Console Filter
extension <http://forums.mozillazine.org/viewtopic.php?t=264146>
Comment 4 User image Peter van der Woude [:Peter6] 2005-08-29 13:23:46 PDT
*** Bug 306223 has been marked as a duplicate of this bug. ***
Comment 5 User image Peter van der Woude [:Peter6] 2005-08-29 13:23:51 PDT
*** Bug 302211 has been marked as a duplicate of this bug. ***
Comment 6 User image David Baron :dbaron: ⌚️UTC-8 2005-08-29 14:18:54 PDT
Perhaps this should be general filtering based on nsIScriptError::category for
messages that implement nsIScriptError (and put those that don't, or those with
a null category, in "Other"), so that when new categories of errors are created,
they'll just show up.  Localizing the categories would be an issue, though --
they're currently just unlocalized ASCII strings, and from the interface
definition it's not clear whether or not they're supposed to be user-readable names.

The categories currently used in the tree are:
  chrome registration
  CSS Loader
  CSS Parser
  DOM:HTML
  HTML
  ImageMap
  malformed-xml
  XBL Content Sink
  XUL Document
(These names could easily be changed.)

In any case, any solution to removing some of these classes of errors should
probably use the known nsIScriptError::category strings for these errors.
Comment 7 User image Martijn Wargers [:mwargers] 2005-09-01 14:22:06 PDT
Created attachment 194588 [details] [diff] [review]
patch

Well, this is basically a patch made from Jiri Znamenacek's code in bug 264162,
with some improvements (I hope). It's not localised yet.
Is this something that's in the good direction?
Comment 8 User image Tom Chiverton 2005-09-14 09:08:46 PDT
I agree. It's silly to call it a javascript console when it actually logs all 
sorts of errors from CSS (and others) too. 
 
I take it CSS errors aren't loged to the Javascript Console in actual Firefox 
1.5, only the beta's ? 
 
(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 (No IDN) 
Firefox/1.4) 
Comment 9 User image Boris Zbarsky [:bz] (still a bit busy) 2005-09-14 09:34:34 PDT
> It's silly to call it a javascript console

Indeed.  We've had a bug open for years to rename it to be the error console.

> I take it CSS errors aren't loged to the Javascript Console in actual Firefox 
> 1.5

I don't know what gave that impression.  CSS errors will be logged to the
console service in the final release.  What the console UI chooses to do with
them is a separate issue.
Comment 10 User image Tom Chiverton 2005-09-15 05:29:59 PDT
(In reply to comment #9)
> > It's silly to call it a javascript console
> Indeed.  We've had a bug open for years to rename it to be the error console.

Do you have the # so I can at least vote on it ?
 
> > I take it CSS errors aren't loged to the Javascript Console in actual Firefox 
> > 1.5
> 
> I don't know what gave that impression.  CSS errors will be logged to the
> console service in the final release.  What the console UI chooses to do with
> them is a separate issue.

That's a major change from 1.0.x (which only loged JS errors in the JS console),
is really irratating, and means everyone* will need to install the filter extension.
Comment 11 User image Boris Zbarsky [:bz] (still a bit busy) 2005-09-15 21:27:04 PDT
> Do you have the # so I can at least vote on it ?

Not offhand.

> That's a major change from 1.0.x (which only loged JS errors in the JS
> console),

Yes, it just had no CSS error logging whatsoever.
Comment 12 User image Tom Chiverton 2005-09-16 01:09:21 PDT
(In reply to comment #11) 
> > That's a major change from 1.0.x (which only loged JS errors in the JS 
> > console), 
>  
> Yes, it just had no CSS error logging whatsoever. 
 
But logging them at error rather than warning really, really devalues the 
console as a dev. tool. 
 
 
Comment 13 User image Boris Zbarsky [:bz] (still a bit busy) 2005-09-16 08:08:33 PDT
Well, they _are_ errors.  The UI aspect is exactly what this bug is about.
Comment 14 User image Tom Chiverton 2005-09-16 08:24:09 PDT
IMVHO an error is something you can't recover from. 
These are warnings, because Firefox is quite happy to carry on. 
With the settings as in the beta, an awful lot of sites are suddenly going to 
delugue 'errors' on people. If the setting itself can't be as in 1.0.x then a 
filter of some sort must ship with Firefox. 
Comment 15 User image Boris Zbarsky [:bz] (still a bit busy) 2005-09-16 08:35:50 PDT
I agree that Firefox needs a filter; again, that's what this bug is about. 
Patches accepted.
Comment 16 User image Martijn Wargers [:mwargers] 2005-09-16 08:49:10 PDT
Well, I attached a patch, which is more or less Jiri Znamenacek's code in bug
264162. Is it any good?
Comment 17 User image Peter van der Woude [:Peter6] 2005-09-16 08:50:05 PDT
see also http://forums.mozillazine.org/viewtopic.php?t=318102
for Console²
Comment 18 User image Boris Zbarsky [:bz] (still a bit busy) 2005-09-16 09:09:32 PDT
Comment on attachment 194588 [details] [diff] [review]
patch

To be truthful, no idea... I haven't done anything with the UI in years.  I bet
Mike can tell whether it's good, though (or pass the review off to someone else
who can).
Comment 19 User image Stebs 2005-09-16 10:29:09 PDT
Whoa, this Console2 Extension is great stuff (and working just fine).
Is it really too late in the game to integrate this as Extension, just like
Reporter, Talkback etc.?
May be worth it, apparently: "On the way, this extension proposes fixes to the
following bugs: 68025, 81209, 83019, 86093, 175517, 213950, 238898, 265871,
275265, 302211, 305206 and 307354. "
Comment 20 User image Tom Chiverton 2005-09-19 01:14:34 PDT
Stebs: I agree, this extension is spot on, and more user friendly than the
previous suggestion.

It really should be a 'default' extension that FF ships with.
Comment 21 User image Martijn Wargers [:mwargers] 2005-09-19 02:43:48 PDT
Yes,  I agree that Console² is way better, and probably approximately the way it
should be done in Firefox/Mozilla.
Comment 22 User image Shayne Jewers 2005-09-19 15:49:45 PDT
(In reply to comment #10)
> Do you have the # so I can at least vote on it ?

bug 265871?
Comment 23 User image Mike Connor [:mconnor] 2005-11-10 08:22:40 PST
Comment on attachment 194588 [details] [diff] [review]
patch


>+  <broadcasterset id="ModeFilterBroadcasters">
>+    <broadcaster id="Console:modeFilter:All" checked="true"
>+                 label="Show All" accesskey="s"
>+                 oncommand="changeModeFilter('All');"/>
>+    <broadcaster id="Console:modeFilter:JS"
>+                 label="JS" accesskey="j"
>+                 oncommand="changeModeFilter('JS');"/>
>+    <broadcaster id="Console:modeFilter:CSS"
>+                 label="CSS" accesskey="c"
>+                 oncommand="changeModeFilter('CSS');"/>
>+  </broadcasterset>

Localize this, please, and it doesn't need a separate broadcasterset.

>@@ -116,16 +128,20 @@
>   <toolbox>
>     <toolbar class="chromeclass-toolbar" id="ToolbarMode">
>       <toolbarbutton type="radio" group="mode" observes="Console:modeAll"/>
>       <toolbarbutton type="radio" group="mode" observes="Console:modeErrors"/>
>       <toolbarbutton type="radio" group="mode" observes="Console:modeWarnings"/>
>       <toolbarbutton type="radio" group="mode" observes="Console:modeMessages"/>
>       <toolbarseparator/>
>       <toolbarbutton observes="Console:clear"/>
>+      <toolbarseparator/>
>+      <toolbarbutton type="radio" group="modeFilter" observes="Console:modeFilter:All"/>
>+      <toolbarbutton type="radio" group="modeFilter" observes="Console:modeFilter:JS"/>
>+      <toolbarbutton type="radio" group="modeFilter" observes="Console:modeFilter:CSS"/>
>     </toolbar>

I think it makes more sense to put these at the start of the toolbar.


>-  
>+
>+					var categoryFlag = '';
>+					switch (aObject.category) {
>+						case "XPConnect JavaScript":
>+							categoryFlag = 'js-xpconnect';
>+							break;
>+						case "content javascript":
>+							categoryFlag = 'js-content';
>+							break;
>+						case "CSS Loader":
>+							categoryFlag = 'css-loader';
>+							break;
>+						case "CSS Parser":
>+							categoryFlag = 'css-parser';
>+							break;
>+						default:
>+							break;
>+					}
>+

tabs are evil!  s/categoryFlag/errorCategory/ too.
Comment 24 User image Sebastian Werner 2005-11-16 12:03:08 PST
This is also not fixed in firefox 1.5 rc2. I think this should be classified as a "blocker". I think all web developers will hate this default bug if you really want to release firefox 1.5 including this bug.
Comment 25 User image Peter van der Woude [:Peter6] 2005-11-16 12:20:33 PST
(In reply to comment #24)
> This is also not fixed in firefox 1.5 rc2. I think this should be classified as
> a "blocker". I think all web developers will hate this default bug if you
> really want to release firefox 1.5 including this bug.
> 
Stop crying and use Console² untill it is fixed.
Comment 26 User image Tom Chiverton 2005-11-16 13:30:36 PST
It is hardly crying when it is a good and useful feature that has been wrecked (because useful errors are now often swamped by warnings about stuff that used to be silent).

"You can install an extension" is a useful workaround but not a fix.
Comment 27 User image Ben Basson 2005-11-16 13:33:31 PST
Nonetheless, it's too late in the cycle for this to be included and the patch has been denied review as-is. Please keep advocacy comments out of Bugzilla.
Comment 28 User image Sebastian Werner 2005-11-16 13:41:57 PST
Sorry. This was not meant to be recognized as crying. I have already voted for it. But I just want to tell you again that I, as a software developer, can just not endorse, that a new final version of a product, has one bug which makes an in the previous version lighter but workable part nearly unusable. I just think this must get more focus. We are already at RC2 and it seems to be only weeks before the final release. And this should really be fixed in my humble opinion. What's about to install console² in a default firefox setup (like the dom inspector)?
Comment 29 User image Martijn Wargers [:mwargers] 2005-11-20 12:28:16 PST
Created attachment 203738 [details] [diff] [review]
patch2

Ok, I addressed the review comments in this patch.
Comment 30 User image Matthias Versen [:Matti] 2005-12-09 23:42:58 PST
*** Bug 319764 has been marked as a duplicate of this bug. ***
Comment 31 User image Martijn Wargers [:mwargers] 2005-12-28 04:40:43 PST
Comment on attachment 203738 [details] [diff] [review]
patch2

This patch is missing the console.css changes.

Also, there is still a tab in the patch:
+            case "XPConnect JavaScript":
+          	  errorCategory = 'js-xpconnect';
+              break;
Comment 32 User image Simon Bünzli 2005-12-28 05:15:10 PST
(In reply to comment #31)
> +            case "XPConnect JavaScript":
> +              errorCategory = 'js-xpconnect';
> +              break;

Why don't you use the error category as indicated by the error itself? If you did, this would enable extensions to more easily enhance the console's filters (see bug 306223).

Additionally, I'm not sure whether you really filter all possible messages as intended. See http://forums.mozillazine.org/viewtopic.php?p=1758678#1758678 for a pretty complete list of categories for Gecko 1.8. You seem to miss at least three of them for JavaScript.

Finally, you might have to take the fix of bug 264162 into account. If the new preference is switched off, the CSS button will simply display an empty console. And you might also want to add a dependency on bug 312962 which should make the difference of JS and CSS messages more obvious (currently many users wouldn't even notice that not all errors are JavaScript ones).
Comment 33 User image Martijn Wargers [:mwargers] 2005-12-28 05:30:20 PST
Thanks Simon, adding dependencies to the bug.
I can't really answer your questions at the moment, I hope I'll have a new,  - improved with your comments - patch in the next days.
But you're welcome to make that patch yourself, if you like to.
Comment 34 User image James Edwards 2006-05-03 09:24:39 PDT
When is this bug going to be fixed? It is a bug - what it reports here are *not* errors (or at least, not necessarily, because they include warnings over thigns that are valid syntax, but simply not understood by Mozilla)
Comment 35 User image Richard Connamacher 2006-06-29 00:58:54 PDT
I think the handling of CSS errors themselves should be adjusted as well. Grammatical errors are definitely errors, but unknown properties are not really errors, as the CSS spec instructs that they should be ignored for compatibility with future versions. (Browser-specific hacks fall here too, and this is something that even Mozilla is guilty of; ahem, display: -moz-inline-block, ahem.)

It would make more sense if unknown properties were, in fact, warnings, while reporting grammatical errors as errors.

It is very difficult to look through the list of CSS errors for the real trouble-makers when it's flooded with all sorts of other, more benign "errors." Even if the othe proposed filters were put in place (which would be great), debugging CSS would still be cumbersome.

See: http://www.w3.org/TR/REC-CSS1#forward-compatible-parsing
Comment 36 User image Simon Bünzli 2006-06-29 01:04:57 PDT
(In reply to comment #35)
> I think the handling of CSS errors themselves should be adjusted as well.
That has been done several months ago (see bug 264162).
Comment 37 User image BoffinbraiN 2007-07-31 06:04:18 PDT
Here's another idea for formatting the toolbar buttons.  Using radio buttons is rather ugly, and requires the redundant option "JavaScript & CSS".  Using toggle buttons, which act like check-boxes, would look better, while still very intuitive.

The toolbar would look like this:

> All  Errors  Warnings  Messages  |  JavaScript  CSS  Other  |  Clear 

Alternatively, if more types of errors were to be added, a drop-down list button would be better.
Comment 38 User image Cees T. 2007-12-17 05:48:23 PST
I use Firebug (https://addons.mozilla.org/nl/firefox/addon/1843), but looking at the sweet looking Error Console, i think the (Java)Script errors are listed under "Errors", the CSS warnings are under "Warnings", and the internal browser errors are under "Messages".

Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 with Aero Fox 1.0.4 theme.
Comment 39 User image (Unavailable until Apr 3) [:bgrins] 2016-06-27 07:47:36 PDT
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 40 User image Zack Weinberg (:zwol) 2016-06-27 09:42:14 PDT
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 41 User image BoffinbraiN 2016-06-27 13:25:04 PDT
(In reply to Zack Weinberg (:zwol) from comment #40)

Your comment is rather ironic because in this case, the bug really is no longer valid. The developer console allows independent filtering for the categories Net, CSS, JS, Security, Logging and Server, along with various sub-levels for each. I recommend you re-close it.
Comment 42 User image J. Ryan Stinnett [:jryans] (use ni?) 2016-06-27 13:26:44 PDT
I agree it appears there is now nothing to do here.
Comment 43 User image (Unavailable until Apr 3) [:bgrins] 2016-06-27 13:27:31 PDT
(In reply to BoffinbraiN from comment #41)
> (In reply to Zack Weinberg (:zwol) from comment #40)
> 
> Your comment is rather ironic because in this case, the bug really is no
> longer valid. The developer console allows independent filtering for the
> categories Net, CSS, JS, Security, Logging and Server, along with various
> sub-levels for each. I recommend you re-close it.

Thanks for confirming

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