Closed Bug 404419 Opened 14 years ago Closed 14 years ago
XML not displayed
When trying to view update information from aus2.m.o (see URL), there is a blank page instead of displayed XML, and this error in the Error Console: Error: Source File: jar:file:///Users/nrthomas/Desktop/20071119_0331.app/Contents/MacOS/chrome/toolkit.jar!/content/global/xml/XMLPrettyPrint.xsl Line: 48, Column: 99 Source Code: <link href="chrome://global/content/xml/XMLPrettyPrint.css" type="text/css" rel="stylesheet"/> For mac, this occurs in the build from 20071119_0331 but not 20071119_0253. Which points to bug 401613, although bug 403678 also landed in this window.
Assignee: nobody → peterv
Priority: -- → P2
Target Milestone: --- → mozilla1.9 M10
Maybe we're not ready yet for stopping the parser on errors. nsStyleLinkElement::DoUpdateStyleSheet was returning the NS_ERROR_NOT_AVAILABLE from CSSLoaderImpl::LoadInlineStyle/LoadStyleLink. Bailing out early if the CSSLoader is disabled works.
nsScriptElement sanitizes the error codes that it returns (see http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/base/src/nsScriptElement.cpp&rev=3.9&mark=190-196#188). Maybe we should do the same thing in nsStyleLinkElement::DoUpdateStyleSheet too?
Comment on attachment 289479 [details] [diff] [review] v1 No need for the else-after-return; other than that looks fine. But you're right; we should consider sanitizing errors here... but on the other hand, if there's an OOM in CSSLoader, maybe we do want to abort the XML parser. Perhaps the CSSLoader should silently return NS_OK when disabled?
Actually, silent NS_OK could be tough given the API. So I think this patch is the way to go.
Flags: blocking1.9? → blocking1.9+
Status: NEW → RESOLVED
Closed: 14 years ago
OS: Mac OS X → All
Hardware: PC → All
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.