Closed
Bug 607088
Opened 14 years ago
Closed 14 years ago
External stylesheet errors are not displayed
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
DUPLICATE
of bug 606498
People
(Reporter: pcwalton, Unassigned)
References
Details
The patch in bug 605492 adds a new nsIScriptError2 message, which is needed for the Web Console to be able to find the originating window for a script error. The CSS parser doesn't use this interface, which means that we can't find the originating window for external style sheets. To fix this, the CSS parser is going to need to be updated to use InitWithWindowID() when creating its error message [1]. The tricky part here is making sure the CSS scanner knows about the originating window ID at all times. This issue is making tests fail for the patch I have ready for bug 597136, which removes the window.onerror workaround that the Console was using before. [1]: http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.cpp#436
Comment 1•14 years ago
|
||
The plan is to fix this bug within bug 606498.
Comment 2•14 years ago
|
||
> The tricky part here is making sure the CSS scanner knows about the originating
> window ID at all times.
It clearly doesn't; for one thing there are stylesheets that are not associated with any particular window (UA sheets, user sheets).
Unless you meant knows about the originating window id in all cases in which there is one?
Note that window.onerror doesn't see CSS errors, so I'm not sure why this issue causes the failure you describe...
Reporter | ||
Comment 3•14 years ago
|
||
(In reply to comment #2) > It clearly doesn't; for one thing there are stylesheets that are not associated > with any particular window (UA sheets, user sheets). > > Unless you meant knows about the originating window id in all cases in which > there is one? Right. > Note that window.onerror doesn't see CSS errors, so I'm not sure why this issue > causes the failure you describe... Sorry, I neglected to mention the most important part. The reason tests are failing is that the patch in bug 597136 *also* removes the logic that maps URIs to Web Console instances. I removed that bit because it no longer needs to exist with the addition of the nsIScriptError2 interface, in theory. However, there are some Web Console tests that check for the reporting of CSS errors in inline style sheets. Now that I think about it, it makes more sense to go ahead and leave that logic in as a fallback, in case the window ID is not present on a script error that the Web Console sees. This will allow us to land the fix for bug 597136 sooner, because it will avoid existing test regressions. However, in order to catch external script errors, we should still implement this functionality. I have the beginnings of a patch to the layout code that threads a window ID through the CSS parser. If you'd like to take this bug, I can post what I have so far, if this is indeed the approach you'd like me to take.
Comment 4•14 years ago
|
||
> leave that logic in as a fallback, in case the window ID is not present on a > script error Yep. > we should still implement this functionality Again, yep. Passing the document to the CSS parser is a better idea than passing the window ID, I suspect; the error reporting codepath can then either just get the id or get+cache it. If we do pass in the ID, I'd like to see some numbers for microbenchmarks testing setting of .style.height or whatnot.
Reporter | ||
Comment 5•14 years ago
|
||
(In reply to comment #3) > However, in order to catch external script errors Err, sorry, I meant external style sheet errors.
Comment 6•14 years ago
|
||
Requesting blocking status because errors on stylesheets that come from other sites simply do not show up in the console.
blocking2.0: --- → ?
Summary: CSS style errors should use nsIScriptError2 → External stylesheet errors are not displayed
Comment 7•14 years ago
|
||
This is taken care of by the bug 606498 work.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
blocking2.0: ? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•