275265 - add javascript&CSS/javascript/CSS radiobuttons to the Error Console

Status: RESOLVED WONTFIX

(Toolkit Graveyard :: Error Console, enhancement)

Description

[Peter van der Woude [:Peter6]]

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

[Stipe Kotarac]

I think it would be a nice change. I'll vote for this.

Comment 2

[Ben Basson]

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

[Nickolay_Ponomarev]

See also bug 296664; as a workaround use the (wonderful) Console Filter
extension <http://forums.mozillazine.org/viewtopic.php?t=264146>

Comment 4

[Peter van der Woude [:Peter6]]

*** Bug 306223 has been marked as a duplicate of this bug. ***

Comment 5

[Peter van der Woude [:Peter6]]

*** Bug 302211 has been marked as a duplicate of this bug. ***

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Martijn Wargers (dead)]

Attachment: 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

[Tom Chiverton]

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

[Boris Zbarsky [:bzbarsky]]

> 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

[Tom Chiverton]

(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

[Boris Zbarsky [:bzbarsky]]

> 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

[Tom Chiverton]

(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

[Boris Zbarsky [:bzbarsky]]

Well, they _are_ errors.  The UI aspect is exactly what this bug is about.

Comment 14

[Tom Chiverton]

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

[Boris Zbarsky [:bzbarsky]]

I agree that Firefox needs a filter; again, that's what this bug is about. 
Patches accepted.

Comment 16

[Martijn Wargers (dead)]

Well, I attached a patch, which is more or less Jiri Znamenacek's code in bug
264162. Is it any good?

Comment 17

[Peter van der Woude [:Peter6]]

see also http://forums.mozillazine.org/viewtopic.php?t=318102
for Console²

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

[Stebs]

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

[Tom Chiverton]

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

[Martijn Wargers (dead)]

Yes,  I agree that Console² is way better, and probably approximately the way it
should be done in Firefox/Mozilla.

Comment 22

[Shayne Jewers]

(In reply to comment #10)
> Do you have the # so I can at least vote on it ?

bug 265871?

Comment 23

[Mike Connor [:mconnor]]

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

[Sebastian Werner]

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

[Peter van der Woude [:Peter6]]

(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

[Tom Chiverton]

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

[Ben Basson]

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

[Sebastian Werner]

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

[Martijn Wargers (dead)]

Attachment: patch2

Ok, I addressed the review comments in this patch.

Comment 30

[Matthias Versen [:Matti]]

*** Bug 319764 has been marked as a duplicate of this bug. ***

Comment 31

[Martijn Wargers (dead)]

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

[Simon Bünzli]

(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

[Martijn Wargers (dead)]

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

[James Edwards]

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

[Richard Connamacher]

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

[Simon Bünzli]

(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

[BoffinBrain]

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

[Cees T.]

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

[Brian Grinstead [:bgrins]]

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

[Zack Weinberg (:zwol)]

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

[BoffinBrain]

(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

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I agree it appears there is now nothing to do here.

Comment 43

[Brian Grinstead [:bgrins]]

(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