Closed
Bug 65469
Opened 24 years ago
Closed 20 years ago
get CSS error reporting working
Categories
(Core :: CSS Parsing and Computation, defect, P4)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: dbaron, Assigned: dbaron)
References
(Depends on 1 open bug)
Details
Attachments
(8 files)
19.86 KB,
patch
|
Details | Diff | Splinter Review | |
21.59 KB,
patch
|
Details | Diff | Splinter Review | |
24.33 KB,
patch
|
Details | Diff | Splinter Review | |
24.68 KB,
patch
|
Details | Diff | Splinter Review | |
24.67 KB,
patch
|
Details | Diff | Splinter Review | |
24.70 KB,
patch
|
Details | Diff | Splinter Review | |
910 bytes,
patch
|
Details | Diff | Splinter Review | |
1.15 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
This is a bug to finish and perhaps enable (at least in DEBUG builds) CSS error reporting. I have a patch that makes it actually work pretty well, although there aren't detailed errors for any of the value parsers - just "error parsing value for property X". I've gotten rid of the errors that weren't errors, and I've made the scanner accumulate errors so we only print one report per error. Patch coming (although it's just a first installment).
Assignee | ||
Comment 1•24 years ago
|
||
Assignee | ||
Comment 2•24 years ago
|
||
And at some point I should make it learn the right numbers for CSS evaluated from within HTML or JavaScript!
Assignee | ||
Comment 3•24 years ago
|
||
http://www.bath.ac.uk/%7Epy8ieh/internet/importtest/extra/importafterimport.html is an interesting test case
Assignee | ||
Comment 4•24 years ago
|
||
I need to figure out why it doesn't report "//" comments.
Comment 5•24 years ago
|
||
David: I assume you are going to move the strings into a properties file before checking in, right?
QA Contact: chrisd → ian
Assignee | ||
Comment 6•24 years ago
|
||
Certainly not until I get everything else working (since it's a lot easier to understand the code if the strings are right there). And even then this might be hard. And I might want to check in stages, since I may not get to finishing this for a while.
Assignee | ||
Comment 7•24 years ago
|
||
BTW, I really don't like the design of this solution at all. I'd greatly prefer to pass errors as return values that indicated the error, except that would be a bit more work, and also require modifing the CSS parser itself rather than just adding code around the edges. However, I may still try to do it...
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 8•24 years ago
|
||
Assignee | ||
Comment 9•24 years ago
|
||
I think this current patch would be more useful for chrome developers than what's currently in the tree. However, pushing off to Mozilla 1.1 when I may have time to rework the error handling in the CSS parser and do the whole thing right. If anyone thinks I should try to get what I have checked in, give a yell.
Target Milestone: mozilla0.9 → mozilla1.1
Assignee | ||
Updated•24 years ago
|
OS: Linux → All
Hardware: PC → All
Assignee | ||
Comment 10•24 years ago
|
||
Assignee | ||
Comment 11•24 years ago
|
||
I'd either like to check in the improvements that I currently have to the CSS error reporting or remove it from the tree. I'd prefer the first because I think this is a useful debugging tool for others, although others don't seem to be using it. At some point I'd hope to do this the right way, but that would involve significant changes to the CSS parser. Any thoughts?
Assignee | ||
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
David, I'd like to see the changes get in. I agree that it is a very nice developer-feature. I'm wondering why you would *not* want to get it in?
Assignee | ||
Comment 14•24 years ago
|
||
Assignee | ||
Comment 15•24 years ago
|
||
I love it... r=glazman For the future, I suggest consistency in error messages with W3C CSS validator
Comment 17•24 years ago
|
||
Don't the error messages need to be localizable?
Assignee | ||
Comment 18•24 years ago
|
||
blake: As I've said above (2001-01-19 06:41), this is work in progress. It's not enabled yet, and it's a lot easier to work with when the strings are right in front of me. The reasons I want to check it in are: * I don't want to have tons of changes in my tree * It's a useful debugging feature that I want people who are writing chrome to use The whole thing is really a hack, and I'd prefer not to localize it until it's written properly, which requires rewriting much of the CSS parser's error handling. And I'd rather not do that until CSS3's grammar is finished...
Comment 19•24 years ago
|
||
sr=attinasi. Thanks David.
Assignee | ||
Comment 20•24 years ago
|
||
Assignee | ||
Comment 21•24 years ago
|
||
FWIW, the previous (large) patch was checked in 2001-03-05 17:57 PST.
Comment 22•24 years ago
|
||
glazou: Considering how useful the W3C CSS Validator error messages are, I would rather rely on David's wording...
Comment 23•24 years ago
|
||
David, the change looks fine, except I don't know what this is: + * vim:ts=2:et:sw=2: Do you want that there, and why have I not seen it in other files? I'm guessing it does for VIm what the other line does for eMacs... Regardless, [s]r=attinasi
Assignee | ||
Comment 24•23 years ago
|
||
Above patch was checked in with bug 83482.
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla1.1 → Future
Assignee | ||
Updated•23 years ago
|
Priority: P3 → P4
Comment 25•23 years ago
|
||
So... what's the status on this bug? It's been almost 3/4 of a year since the patch was checked in. Has this bug been squashed for 8.5 months and not marked as such?
Assignee | ||
Comment 26•23 years ago
|
||
More work needs to be done before it can be turned on.
Comment 27•23 years ago
|
||
Would CSS parser warnings hurt forward compatibility?
Assignee | ||
Comment 28•23 years ago
|
||
They would cause us to give errors on things in future versions of CSS -- but they would be useful for web developers to see what it is that Mozilla doesn't understand. They wouldn't affect anything other than the actual warnings/errors being displayed.
Assignee | ||
Comment 29•22 years ago
|
||
*** Bug 162425 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 30•22 years ago
|
||
Issues that should block this being turned on: * bug 187007 - localizability * getting the line numbers right for STYLE elements and STYLE attributes (via HTML, XML, and XUL content sinks)
![]() |
||
Comment 31•22 years ago
|
||
*** Bug 136158 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 32•21 years ago
|
||
Hmmm for line numbers, style elements are easy ("do what script does"), but style attributes are somewhat harder. Even if we fix them to work right during parsing (which may need a change to the signature of SetAttr or at least some sort of evil hackery), what line number should be reported when .style is set via script?
Comment 33•21 years ago
|
||
bz: for dynamic style attribute setting, the setter might include "jsdbgapi.h" and use JS_FrameIterator, JS_GetFramePC, and JS_PCToLineNumber; also JS_GetFrameScript and JS_GetScriptFilename to good advantage. /be
Comment 34•21 years ago
|
||
All that jsdbgapi.h cruft should of course be hidden under nsIScriptContext or some such similar interface. /be
Assignee | ||
Comment 35•20 years ago
|
||
The minimo XXX comment is for whenever somebody goes through to find all the little things in layout that could be turned off for minimo -- there's no particular reason to do this one now and not others...
Assignee | ||
Updated•20 years ago
|
Attachment #159509 -
Flags: superreview?(bzbarsky)
Attachment #159509 -
Flags: review?(bzbarsky)
![]() |
||
Comment 36•20 years ago
|
||
Comment on attachment 159509 [details] [diff] [review] patch to enable r+sr=bzbarsky
Attachment #159509 -
Flags: superreview?(bzbarsky)
Attachment #159509 -
Flags: superreview+
Attachment #159509 -
Flags: review?(bzbarsky)
Attachment #159509 -
Flags: review+
Assignee | ||
Comment 37•20 years ago
|
||
Fix checked in to trunk, 2004-09-20 21:41 -0700.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 38•20 years ago
|
||
It would be nice to be able to switch CSS errors off, or filter them. Important javascript errors are overseen within hundrets of them...
Comment 39•20 years ago
|
||
(In reply to comment #38) > It would be nice to be able to switch CSS errors off, or filter them. Important > javascript errors are overseen within hundrets of them... See bug 264162 - css error reporting should be pref-controlled.
Comment 40•20 years ago
|
||
Bug 264162 is about the client (=browser) side. But what if the server side gets a chance to control that? I can imagine webmasters are including proprietary properties in their CSS to get around the trouble of maintaining multiple user-agent specific CSSs. Wouldn't be a Mozilla specific CSS instruction along the line... "If user-agent == Mozilla then skip next property" ...helpful, without conflicting with W3C philosophy or evangelism? I'm aware that this may sound a bit pointless since unknown properties are skipped anyway. Just thinking about a way not to let CSS writers look like **** coders while they in reality just want to maintain cross-browser compatibility.
You need to log in
before you can comment on or make changes to this bug.
Description
•