Closed Bug 264162 Opened 17 years ago Closed 15 years ago
css error reporting should be pref-controlled
6.68 KB, application/octet-stream
5.98 KB, patch
|Details | Diff | Splinter Review|
Currently, CSS error-reporting is a build-time option. Would there be significant performance or bloat impact if it were made a pref or JS Console toggle instead? Rationale: At least one person has complained to me that they don't like using the suite for web development because JS errors get lost among the CSS errors of other sites they are visiting. Also, it would then more closely match e.g. dump() support and JS Strict warnings support, which are both prefs. Gerv
Gerv, the JS console already knows which errors it's getting are CSS errors and which ones are JS errors. It could easily filter them out as desired at display time (the same way that it can already divide things into the warnings/messages/errors categories and only display some subset). Pretty much anyone with a modicum of XUL programming knowledge should be able to implement that. Wouldn't that be a more reasonable approach than complicating the back end with extra prefs? See also bug 228205 for more information on the way we would like to move with the error console back end and ui.... Note that this is unlike dump() or strict warning support in that these are real errors no different from JS errors, <map> parsing errors, security exceptions, and the various other errors that are reported to the "JS Console" (which has been itching to be renamed "Error Console" for years now).
bz: but CSS errors also appear in the "-console" console, don't they? And there's no way to turn them off there. Which annoys me :-) But fair enough. I just wanted to raise the idea. Gerv
> bz: but CSS errors also appear in the "-console" console, don't they? Yes, in debug builds. That could be fixed up so that the output to the text console is done by a console service listener (instead of by raw printf). Then this listener could follow the JS console settings. But that's debug builds. "Real people" (other than the development team) don't use debug builds.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Is there any way of creating a dynamic CSS style to hide the rows that aren't from a specific source? That would make it possible to create a menulist of all discovered sources and quickly filter based on the selected item. Otherwise it could still be done by manually looping through all of the rows and showing/hiding them as appropriate, plus also checking when adding new rows.
> Is there any way of creating a dynamic CSS style to hide the rows that aren't > from a specific source? If the document has a stylesheet that can be edited via DOM, then yes. See http://w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSStyleSheet the insertRule and deleteRule methods.
OK, due to the total lack of progress on the front end side, I'll make a pref.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Attachment #206269 - Flags: review? → review?(shaver)
Well, I made a front end patch (based on Jiri's code) in bug 275265.
Comment on attachment 206269 [details] [diff] [review] patch to add pref and change from error to warning r=shaver!
Attachment #206269 - Flags: review?(shaver) → review+
Comment on attachment 206269 [details] [diff] [review] patch to add pref and change from error to warning >Index: layout/style/nsCSSScanner.cpp >+#define CSS_ERRORS_PREF "layout.css.report_errors" >+ >+PR_STATIC_CALLBACK(int) CSSErrorsPrefChanged(const char *aPref, void *aClosure) Both the define and the function decl should be inside #ifdef CSS_REPORT_PARSE_ERRORS. With that, sr=bzbarsky
Comment on attachment 206269 [details] [diff] [review] patch to add pref and change from error to warning sr=bzbarsky
Attachment #206269 - Flags: superreview?(bzbarsky) → superreview+
Checked in to trunk.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → FIXED
Any chance of getting this on branch as well?
Comment on attachment 206269 [details] [diff] [review] patch to add pref and change from error to warning a- for 18.104.22.168, you don't (yet) need approvals for 1.8.1
Attachment #206269 - Flags: approval22.214.171.124? → approval126.96.36.199-
*** Bug 316200 has been marked as a duplicate of this bug. ***
Attachment #206269 - Flags: approval1.8.1? → branch-1.8.1?(bzbarsky)
Attachment #206269 - Flags: branch-1.8.1?(bzbarsky) → branch-1.8.1+
Checked in to MOZILLA_1_8_BRANCH.
*** Bug 350858 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.