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

RESOLVED WONTFIX

Status

Toolkit Graveyard
Error Console
--
enhancement
RESOLVED WONTFIX
13 years ago
a year ago

People

(Reporter: Peter6, Unassigned)

Tracking

Dependency tree / graph

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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

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

Comment 2

13 years ago
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

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

Updated

12 years ago
Blocks: 291002
(Reporter)

Comment 4

12 years ago
*** Bug 306223 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 5

12 years ago
*** 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?

Comment 8

12 years ago
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

12 years ago
> 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

12 years ago
(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

12 years ago
> 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

12 years ago
(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

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

Comment 14

12 years ago
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

12 years ago
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?
(Reporter)

Comment 17

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

Comment 18

12 years ago
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).
Attachment #194588 - Flags: review?(mconnor)

Comment 19

12 years ago
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

12 years ago
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.

Comment 22

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

bug 265871?
Assignee: bugs → nobody
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.
Attachment #194588 - Flags: review?(mconnor) → review-

Comment 24

12 years ago
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.
(Reporter)

Comment 25

12 years ago
(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

12 years ago
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

12 years ago
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

12 years ago
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.
Attachment #194588 - Attachment is obsolete: true
Attachment #203738 - Flags: review?(mconnor)
*** Bug 319764 has been marked as a duplicate of this bug. ***
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;
Attachment #203738 - Flags: review?(mconnor)

Comment 32

12 years ago
(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).
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.
Blocks: 306223
Depends on: 264162, 312962

Comment 34

11 years ago
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)
(Reporter)

Updated

11 years ago
Summary: add javascript&CSS/javascript/CSS radiobuttons to javascript console → add javascript&CSS/javascript/CSS radiobuttons to the Error Console

Comment 35

11 years ago
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

11 years ago
(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).
No longer blocks: 291002

Comment 37

10 years ago
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

10 years ago
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.
(Assignee)

Updated

9 years ago
Product: Firefox → Toolkit

Updated

8 years ago
Depends on: 490886

Updated

8 years ago
Blocks: 490886
No longer depends on: 490886
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.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
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.)
Status: RESOLVED → REOPENED
Component: Error Console → Developer Tools: Console
Product: Toolkit → Firefox
Resolution: WONTFIX → ---

Comment 41

a year ago
(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.
Status: REOPENED → RESOLVED
Last Resolved: a year agoa year ago
Resolution: --- → WONTFIX
(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
Component: Developer Tools: Console → Error Console
Product: Firefox → Toolkit
(Assignee)

Updated

a year ago
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.