Closed Bug 607088 Opened 14 years ago Closed 14 years ago

External stylesheet errors are not displayed

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

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
The plan is to fix this bug within bug 606498.
> 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...
(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.
> 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.
(In reply to comment #3)
> However, in order to catch external script errors

Err, sorry, I meant external style sheet errors.
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
No longer blocks: 606498
This is taken care of by the bug 606498 work.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.