I think it would be a nice change. I'll vote for this.
See also bug 296664; as a workaround use the (wonderful) Console Filter extension <http://forums.mozillazine.org/viewtopic.php?t=264146>
*** Bug 306223 has been marked as a duplicate of this bug. ***
*** Bug 302211 has been marked as a duplicate of this bug. ***
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.
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?
> 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.
(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.
Well, they _are_ errors. The UI aspect is exactly what this bug is about.
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.
I agree that Firefox needs a filter; again, that's what this bug is about. Patches accepted.
Well, I attached a patch, which is more or less Jiri Znamenacek's code in bug 264162. Is it any good?
see also http://forums.mozillazine.org/viewtopic.php?t=318102 for Console²
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).
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. "
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.
Yes, I agree that Console² is way better, and probably approximately the way it should be done in Firefox/Mozilla.
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.
(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.
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.
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.
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)?
Created attachment 203738 [details] [diff] [review] patch2 Ok, I addressed the review comments in this patch.
*** Bug 319764 has been marked as a duplicate of this bug. ***
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.
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)
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
(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).
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:126.96.36.199) Gecko/20071127 Firefox/188.8.131.52 with Aero Fox 1.0.4 theme.
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.
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.)
(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.
I agree it appears there is now nothing to do here.
(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